Re: svn commit: r314831 - head/usr.bin/fortune
[ Charset ISO-Latin1 unsupported, converting… ] Is it true you still use mutt to read your e-mail? :-) - Jordan ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r260311 - in head/contrib: gcc gcc/cp gcc/doc gcclibs/include gcclibs/libiberty
On Jan 5, 2014, at 5:18 PM, Pedro Giffuni wrote: > *Anyone working on a GCD-enabled version of grep or sort? :). Look at stdlib/FreeBSD/psort.c in OS X’s Libc (http://www.opensource.apple.com/release/os-x-109/Libc-997.1.1) - that’s the basis for the GCD-aware sort. I don’t know if we got around to doing grep or not - I’d have to look. :) - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r268641 - head/usr.sbin/service
On Jul 15, 2014, at 7:13 PM, dte...@freebsd.org wrote: > I would argue that not all programs are going to like having > a nearly empty environment. Things like TERM and SHLVL > at the very least should be passed (after-all, the boot process > takes place on [a] a terminal and [b] in a shell). Having launchd scrub every processes environment down to nothing, then have environment variables be set explicitly as part of that processes’ “launch contract” was one of the best decisions we ever made at Apple. The Unix process environment is a septic tank, and that’s actually being kind since most septic tanks don’t also contain bottles of nerve gas and the occasional live hand grenade. Many parts of the environment are trivially attackable, and if anyone on the CC line thinks they know the full extent of that attack surface, they’re wrong. Not because there aren’t some extremely smart Unix people in the audience, but because it’s simply impossible to know how each and every environment variable will be used, how it can overflow, or how it can be used to permute a program’s behavior in unpredictable ways. Even if the intention isn’t to be hostile, you can still cause some truly Heisenbergian results by having the environment be unpredictable in nature. It may not be “Unixy”, but Unix didn’t grow up in a world with millions of instances of itself or the big, bad Internet encompassing pretty much every country on earth. Changes need to be made to keep up with the times, and you can rest assured that FreeBSD’s competition is making those changes or has already made them. I also find it a frankly weird assertion that a background service would care about the value of TERM. That sounds like a pretty warped service to me, since assuming interactivity is more the exception than the rule these days. - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r268641 - head/usr.sbin/service
On Jul 15, 2014, at 7:40 PM, dte...@freebsd.org wrote: > I define non-UNIXy as chicanery that makes working in a > POSIX environment more difficult POSIX does not define or mandate any specific set of environment variables. OS X is POSIX and UNIX03 compliant (and qualified to use the Unix trademark, unlike FreeBSD), and I’ve already described its behavior with respect to environment variables. Be careful how you sling terms like POSIX or Unix™ around. ;-) - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r268491 - head/usr.bin/users
On Jul 10, 2014, at 10:20 AM, David Chisnall wrote: > This is important in a wider context. For example, in the project to add > machine-readable output to core utilities, we'd like to be able to parse > these into the same machine-readable format. Apple has the CoreFoundation > library for this, which provides a load of stuff, but most importantly > number, string, date, dictionary, and array types (i.e. the sorts of things > that you'd want in JSON-like serialisation formats). Just as important as CoreFoundation are APIs like CFPreferences. I find it frankly horrifying that in the year 2014, anyone who writes a new daemon or system service will have to invent their own ad-hoc configuration file format in /etc (because, you know, there really aren't enough of them there now) as well as their own out-of-band mechanism for detecting when the configuration data changes. Having a data serialization format would the first step. - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On Apr 4, 2014, at 4:59 PM, David Chisnall wrote: > I believe that libdispatch most likely won't be imported until there is an > in-tree consumer, but it's in ports and there's nothing stopping ports > depending on it if they want to use it... I certainly get and even generally agree with that point of view. It seems like putting the cart before the horse to bring in any technology before there is a use case demanding said technology, right? Right. However, I think there are also occasional exceptions to that rule. The strlcpy() / strlcat() / … family of functions, for example. Until they existed (outside of OpenBSD), nobody really used them pervasively enough to achieve their intended purpose (death to buffer overflows in string handling) and it took bringing them in and essentially saying “see? there! use those now please!” for adoption and conversion of existing string handling code to eventually, over the course of years, become second nature. I think libdispatch is in a very similar category, and you’ll just have to trust me when I say that I’ve had the benefit of watching multiple years worth of slow adoption work its magic there, too. Without libdispatch, you just use pthreads whenever you need to do something in the background. Without libdispatch, you don’t write code (in libraries or applications) which assumes any sort of run loop at all because, well, there isn’t one. Without libdispatch, you still write careful and limited signal handling functions because there’s no signal trampoline to save your butt if you try to do to much in a signal handler. I could go on at length! Libdispatch (with blocks) is, in short, more akin to a programming idiom than a library. Without them, you simply write an entirely different style of synchronous, multi-threaded code with mutex locks and pthread join and cancellation points, yada yada yada. Once libdispatch and blocks are part of the runtime, you slowly leave the old style stuff behind because it’s limited, painful and just nowhere near as sophisticated. To paraphrase something I heard from more than a few dozen software engineers over the years: “Libdispatch is the multithreaded programming paradigm I never knew I always wanted.” There’s a reason it’s been ported to everything from Windows to Android. It’s hard to go back, once you have made the switch. Back to my point, however: I don’t think FreeBSD programmers are ever going to embrace an idiomatic change of that nature (and it’s pretty significant) until it is part of base, so there’s really a deadlock here. What’s worse, I also don’t think anyone in *BSD-land is writing code that’s particularly event-aware (the lack of system-wide notifications kind of speaks to that) largely *because* it’s a PITA to do that without a runloop or handy glue code which makes it trivial, the alternative being to use a background thread that tries to coordinate said events with the foreground and that’s just icky. The end-result of this is that an entire somewhat more modern style of programming, where things are more dynamic in the face of things changing on the system, simply doesn’t happen at the OS level and that’s a shame, because the OS *is* a dynamic environment, particularly in the mobile space. I guess what I’m advocating is nothing less than a leap of faith? - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On Apr 4, 2014, at 5:31 PM, Bryan Drewery wrote: > Respectfully, as a developer, why would I want to use libdispatch and > not libevent? Libevent looks far more portable. Equally respectfully, if you’re comparing libevent and libdispatch at all, then you’re only getting about 10% of what libdispatch actually is. The event handling piece is really just a small fraction of it. For a really nice overview written by someone *not* from Apple, I recommend: http://arstechnica.com/apple/2009/08/mac-os-x-10-6/12/ Libdispatch is also highly portable. I don’t think there’s an OS flavor it *hasn’t* been ported to at this point. - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On Apr 4, 2014, at 5:33 PM, David Chisnall wrote: > The slight problem, however, is that we would still like to be able to build > the base system with a more or less standard C compiler. Blocks are in clang > and are slowly making their way into commercial compilers, but the only two > versions of gcc that support them are the ones shipped by Apple and FreeBSD. Huh. Can I ask what specific need is driving that? As you point out, you’ve got clang and you’ve also got the blocks support from Apple gcc back-ported, so that covers all the architectures you could possibly want to generate code for. Wanting to hold base to some retro K&R standard for its own sake seems… weird… so I must be missing some part of the need statement, hence my question? Thanks, - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On Apr 4, 2014, at 5:55 PM, David Chisnall wrote: > We'd like to kill off gcc 4.2.1 in base, because it doesn't support C11 or > C++11. The lack of C++11 support is a problem because it means gcc > architectures can't build libc++, so they need to use an old libstdc++ to > build C++ things in the base system (which also means that these things can't > take advantage of C++11, which cleans up the language a huge amount). The > prerequisite for this is the availability of external toolchains for the > non-clang platforms. If we could build base with gcc47 from ports, that > would be okay, because then we'd have a modern C/C++ compiler in the base > system and a modern(ish - 4.8 / 4.9 would be better, but 4.7 is a reasonable > baseline) C/C++ compiler in ports to drive an external toolchain. Ah, OK. And I’m guessing there’s been no interest in forward-porting the blocks support to 4.7? That’s kind of… a bummer. I’m guessing the great white hope for all the platforms is a slow convergence on clang then? What is the compiler toolchain master plan? If there’s a wiki somewhere describing it, I’d also be happy to just go read that. > For embedded uses, we'd also like to build FreeBSD with > vendor's-ugly-hacked-up-gcc-of-the-week. This is less of an issue now for > ARM, but MIPS vendors still hack up gcc in such a way that there's no way > that they can get their changes upstreamed and then ship the result with > their chips. I see. That’s pretty ugly indeed - is there a list of FreeBSD MIPS folks doing this somewhere? I ask out of curiosity to know if there’s any collective attempt to chain them all together and insist that they improve clang/MIPS to the point where they can stop doing ugly-ass gcc ports. :) Thanks for all the info. It’s very helpful! - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib
On Apr 4, 2014, at 7:03 PM, David Chisnall wrote: > That said, I think we're increasingly going to be using LLVM for things that > are beyond just simple AOT compilation, so platforms with no LLVM back end > are likely to be left behind. Amen, and a topic worth an entire discussion in its own right, but I’ll spare us that and leave the topic with just one quick anecdote: When we ported MacRuby to LLVM, thus creating in effect a ruby JIT compiler, we were pretty amazed at how quickly the work progressed and how good the performance of the resulting code was. MacRuby later died for other reasons, but its JIT/AOT compilation abilities were amazing enough that we were left wondered why the Python and Perl folks weren’t stampeding over themselves to follow suit. I think the answer there was that they’d already rolled their own bytecode systems, as ultimately did Ruby, and had too much invested in those technologies, but I’m still holding out hope that the “everyone but C/C++” world of languages will eventually converge on LLVM, as seems to be slowly happening with projects like Rubinius and Numba. Not relevant to FreeBSD right now, but who knows the future? - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Compiler toolchain roadmap
On Apr 6, 2014, at 2:34 PM, Adrian Chadd wrote: > So if we want to be taken seriously by those funny companies that make CPUs, > then: Not really religious about that at all, I just wonder the following: 1. How long will it be considered worthwhile to not be able to have various advanced features in base (like blocks, or someday perhaps, more advanced C++ features / GC / yada yada yada) because the lowest common denominator compiler technology, probably not even under control of the project itself (those “weird-ass compiler ports” David mentioned), simply doesn’t support those things? Moreover, there’s not much incentive for the companies in question to modernize their toolchains if FreeBSD is happy to remain somewhere in the 1990s in terms of what compiler features it leverages, and it’s not particularly clear to me how the presence / participation (?) of those companies is being valued in the overall scheme of things. If one lone MIPS R3000 vendor was holding back because it was using the Mongoose-V radiation-hardened part (yeah, that’s a real thing) and FreeBSD for some solution, would that be worth holding the entire project back? No? How about two such vendors? Three? Where do you draw the line? I don’t even pretend to have the answer to that question, I just think it’s a question worth asking. Also, JFYI, I don’t really have any strong personal agenda where this is concerned - I can just keep taking FreeBSD and hacking it up every which way such that “what’s in base” becomes increasingly irrelevant to me, but the more I diverge, the less easy it becomes to upstream stuff back. I already had that experience once at Apple, and it ultimately didn’t hold me back at all so the “omg the cost of forking” argument is no longer one that holds much fear for me, but it’s a shame that all the I18N / UNIX03 / numerics optimization / … work that occurred in the open over the first 3-5 years I was there was never able to benefit FreeBSD because of said divergence, either. 2. What’s the long-term prognosis on a multi-architecture ecosystem? I certainly remember the “good old days” when any company that knew how to solder two transistors together had their own CPU architecture, but those folks have been dying off for decades now. Now we have Intel as the long-dominant 900 pound gorilla, which is why FreeBSD originally chose to focus almost exclusively on that architecture (and I think that was a smart decision), and the smaller but still feisty ARM architecture. That’s about it. Yes, I know about the others, but just because a port *can* be done doesn’t necessarily mean it *should* be, and I’ll cite the Alpha and Itanium ports as existence proofs of that. Heck, I was a huge proponent of the Alpha port - I wanted a 64 bit version of FreeBSD back then so badly I could taste it, and I personally thought the Alpha was pretty damn cool - I even had one of my own. Didn’t make it such a good idea in hindsight, however. Again, if there’s a common theme in my two bullets there, it’s “show me the numbers!” Sure, I know of vendors who use MIPS and, for that matter, PowerPC and a few other far more obscure architectures as well. I’m familiar with Juniper and Cisco’s interest. I even read Warner’s slides from BSDCan 2008, where a fairly long and slightly sordid tale is told of MIPS support trying repeatedly to get into the tree, being repeatedly rebuffed until it finally somehow took root through a semi-cabalistic effort with dark rituals involving dead chickens and Perforce. Now it’s 2014 and apparently we can’t have nice things in the tree because of MIPS? Maybe I’m over-simplifying the argument, but even simplistically I would easily understand it if you substituted “ARM” or “Intel” because I can count those numbers easily and know without even trying that there are at least 7 zeros involved in the total. Every PC ever shipped. Every Samsung phone. Big and impressive numbers that can’t be argued with. I’m just not getting the same impression from the other architectures under discussion here. - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r280955 - in head/sys: modules/notrandom dev/notrandom
> On Apr 1, 2015, at 11:04 AM, David Chisnall wrote: > > On 1 Apr 2015, at 18:41, Mateusz Guzik wrote: >> >> I guess you were right, this was bad. >> >> I moved the implementation to null.c, I hope this makes everyone happy. >> >> https://lists.freebsd.org/pipermail/svn-src-all/2015-April/101876.html > > This almost certainly does not make people happy: “FreeBSD: Where even April 1st gets a good bike-shedding!” I, personally, am disappointed the 3 BSDs did not merge again this year. - Jordan ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r293720 - head/sys/dev/hyperv/netvsc
Or hellsbells. :-) Sent from my iPhone > On Jan 12, 2016, at 08:49, Gary Jennejohn wrote: > > > Maybe his name should be changed to melbel, which would eliminate > the me/me@ kerfuffle. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r303755 - head/sys/kern
> On Aug 4, 2016, at 10:06 PM, Julian Elischer wrote: > > personally I'd rather we drove a stake through the heart of symbol versioning > and > went back to how it was, when one could work out what was going on. > I certainly miss the ability to get the openssl package to overwrite the base > one, > which I'm told is no longer possible due to versioning. That seems unlikely to be a strategy for long-term success given all of the opportunities for *unintentional* overwriting of symbols. In other words, it’s great when it works for you. It sucks when it works against you. That said, in OS X, Solaris-style symbol versioning didn’t really yield a lot of dividends and turned out to be a far-too-granular way of permuting APIs over time. What tended to happen instead was that symbols got renamed through header hacks (“aliasing”) and the old binaries simply continued to work by calling different versions of function X (newly compiled applications talking to the new implementation). What HAS yielded a lot of dividends in OS X is a two-level namespace for all symbols. To quote the Apple docs: "The two-level namespace feature of OS X v10.1 and later adds the module name as part of the symbol name of the symbols defined within it. This approach ensures a module’s symbol names don’t conflict with the names used in other modules.” This prevents other problems and allows you to move symbols around en-masse in refactoring exercises rather than having to version them. If FreeBSD is genuinely “fed up” with ELF symbol versioning, I might suggest that other alternatives be explored rather than simply going back to the Bad Old Days because they were more predictable. - Jordan ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
