[Zeek-Dev] Re: Proposed change to lambda semantics - shallow copying rather than references
Sounds like a way forward then to both address the current concern, and improve this overall. Does this work for everybody? Robin On Thu, Dec 10, 2020 at 18:26 +, Johanna Amann wrote: > I like this idea, including just deprecating the old syntax - that makes it > explicit what exactly happens. > > Johanna > > On 10 Dec 2020, at 18:06, Robin Sommer wrote: > > > It's interesting how different people have different intuitions on > > semantics here. I also see it as consistent with function arguments, > > that's why I'd be fine it. That said, I was also thinking along the > > same lines of adding explicit capture specifications: deprecate the > > current, capture-spec-less syntax, and generally just require people > > to list what they want to capture; seems like a useful practice to me. > > And then we let them tell Zeek if they want deep or shallow copies > > (but always copies, not references). "when" could then move into the > > same direction as well; maybe it could even change to take a lambda > > instead of its own body. That would simplify the implementation, too. > > > > Robin > > > > On Thu, Dec 10, 2020 at 09:40 -0800, Vern Paxson wrote: > > > > > > for sure on my wishlist is consideration for some deprecation-path, > > > > differentiating-syntax (maybe event just temporary), or other > > > > warning/notice that can help users along instead of potentially > > > > breaking their code outright. > > > > > > Good point. Seems a natural way to do this is to add C++-style [] > > > capture > > > syntax, and a deprecation warning (and the current semantics) if > > > it’s > > > missing. (And maybe no warning if the body doesn’t use any of the > > > outer > > > variables, since that form will continue to work.) > > > > > > — Vern > > > ___ > > > zeek-dev mailing list -- zeek-dev@lists.zeek.org > > > To unsubscribe send an email to zeek-dev-le...@lists.zeek.org > > > > -- > > Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com > > > > ___ > > zeek-dev mailing list -- zeek-dev@lists.zeek.org > > To unsubscribe send an email to zeek-dev-le...@lists.zeek.org -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Proposed change to lambda semantics - shallow copying rather than references
It's interesting how different people have different intuitions on semantics here. I also see it as consistent with function arguments, that's why I'd be fine it. That said, I was also thinking along the same lines of adding explicit capture specifications: deprecate the current, capture-spec-less syntax, and generally just require people to list what they want to capture; seems like a useful practice to me. And then we let them tell Zeek if they want deep or shallow copies (but always copies, not references). "when" could then move into the same direction as well; maybe it could even change to take a lambda instead of its own body. That would simplify the implementation, too. Robin On Thu, Dec 10, 2020 at 09:40 -0800, Vern Paxson wrote: > > for sure on my wishlist is consideration for some deprecation-path, > > differentiating-syntax (maybe event just temporary), or other > > warning/notice that can help users along instead of potentially > > breaking their code outright. > > Good point. Seems a natural way to do this is to add C++-style [] capture > syntax, and a deprecation warning (and the current semantics) if it’s > missing. (And maybe no warning if the body doesn’t use any of the outer > variables, since that form will continue to work.) > > — Vern > ___ > zeek-dev mailing list -- zeek-dev@lists.zeek.org > To unsubscribe send an email to zeek-dev-le...@lists.zeek.org -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: [Zeek-Def] Re: Platform support policy
On Mon, Nov 09, 2020 at 14:16 -0800, Christian Dreibach wrote: > Hah, I asked them too and they actually mentioned their email reply to you! Yeah, and in a further followup email they went a bit further even and committed to generally keeping the previous base image around in the future when new macOS release come out (but not the Xcode image). > https://github.com/zeek/zeek/pull/1268 Excellent. Look like we're all good with our new policy. Thanks for driving this forward, Christian! Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: [Zeek-Def] Re: Platform support policy
On Fri, Nov 06, 2020 at 12:27 -0800, you wrote: > we could just point at our CI? That'd be Dockerfiles for anything > Linux and prepare.sh for FreeBSD and macOS. The benefit would be > that we'd maintain this in one place only. We could invest a bit of > time in documenting the Dockerfiles/prepare.sh scripts so they > explain these? Yeah, agree, that sounds better than maintaining the information separately. > :) -- yes, I mislabeled that one. I actually meant to say > "Maintenance Updates". Fixed in the wiki page. Perfect. :). > I'm definitely not the expert here but it all looks like Catalina > with varying additions: Yeah, I saw that, but not sure if that means they are actively removing older images. I'll see if I can find out. > Btw I didn't include anything about architectures ... for Debian 9 > we currently have a 32-bit container, for some other platforms those > are still available too. Do we still care about 32-bit? Limiting to 64-bit seems fine to me for our current CI platforms. I'm wondering about supporting ARM (32- & 64-bit for Linux, 64bit for future macOS), but looks like CI doesn't support that yet either way: https://github.com/cirruslabs/cirrus-ci-docs/issues/218 Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: [Zeek-Def] Re: Platform support policy
This looks great to me. Some questions/notes: - Which of these come with additional requirements beyond just OS base packages? We should note those. What I can think of: - CentOS: We require devtoolset (which version?) and probably EPEL? I don't recall how people get some of the dependencies in place (bison, flex, cmake). - macOS: Homebrew I suppose. - On CentOS, if we limit support to "full updates", CentOS 7 will drop off soon. I'm wondering if we should use versions with maintenance updates instead? (I'm glad CentOS 6 just went out of life support :-) - Does anybody know if Cirrus keeps previous macOS images available? If so, I'd suggest we keep the two most recent macOS versions. Robin On Thu, Nov 05, 2020 at 20:51 -0800, Christian Dreibach wrote: > Hi folks, > > Sorry for the delay here -- I've now put together a page: > > https://github.com/zeek/zeek/wiki/Platform-Support-Policy > > I've also added an entry to the calendar for macOS (Catalina, using the > availability of images in Cirrus CI as a driver), and I'm putting together a > PR (still a draft) for bringing our CI in line with what's in that page: > > https://github.com/zeek/zeek/wiki/Platform-Support-Policy > > Let me know your thoughts... > > Thanks, > Christian -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Platform support policy
On Wed, Oct 21, 2020 at 14:14 -0700, Christian Kreibich wrote: > https://bit.ly/zeek-os-calendar-ical > https://bit.ly/zeek-os-calendar-google Cool, very nice! Want to start a Wiki page where we collect the pieces for our new policy? Can link to those calendars from there. > I think we've got this, too: when a new release starts, it should go into > CI, and when one drops off LTS EOL, it can go. What do you think? Yeah, though I think we'll need to discuss on per distribution basis what exactly the versions are that we want to support at any point of time (and hence have in CI), plus any additional assumptions we're making (e.g., requiring devtools-X on CentOS). That might be as easy as supporting anything currently in either release or LTS, but spelling it out in the terms of the corresponding distributions would be helpful to make sure everybody's on the same page (e.g., some phrasing of "on Ubuntu, we support the current release as well as any LTS release not EOL yet; and we assume just standard packages"). Could you give that a try on that Wiki page as well for those distros, and then we can send it around to the users' list to see if people can get behind it? One more OS to add is macOS. While nobody knows the deadlines there, we should record how far back we go in supporting previous versions, and what package management we're assuming for dependencies (Homebrew I suppose). Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Platform support policy
On Tue, Oct 06, 2020 at 22:21 -0700, Christian Kreibich wrote: > We could put together a release calendar to remind us when it's time to > update CI. I took a quick look and couldn't immediately find one. I'd be > happy to put one together. Yes, that would be great. The other thing we'll need to do is define the per distribution policies. You could add a 1st stab at that to the calendar as well, or we can do it afterwards. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Platform support policy
[I had posted this on Slack in #development originally, copying here for visibility] We now have the nice list of platforms that Zeek currently supports at: https://github.com/zeek/zeek/wiki/Zeek-Operating-System-Support-Matrix. We however don’t have a policy yet what platform we generally aim to support going forward. Dominik and I discussed this further the other day and came up with a proposal: 1. For each distribution, we decide on a dedicated policy which versions we want to support at any point. A general rule of thumb would be “the two most recent stable releases still within their support window”. But we’d actually look at each distribution and see what policy makes sense, including any additional dependencies we will rely on (like devtools on CentOS). And we do mini-request-for-comments to get feedback from users if we’re making a reasonable choice. 2. We update CI to test those versions, and *only* those versions. 3. We then rely on CI to decide if changes are ok: If, e.g., somebody wants to use a new C++ feature, that’s ok as long as CI passes. If it breaks CI, it won’t go in. The advantage of this is that we won’t rely on having to specify specific compiler versions, which isn’t well-defined (because things also depend on libstdc++ version, system libs, etc.), but instead on whether people can actually compile Zeek on the platforms they are using. A disadvantage is that we’ll need to spend the time to ensure our CI setup keeps matching the policies, and gets updated as distribution updates come out. Thoughts? Dominik added: > I think you’ve summarized it nicely! I’d only add that we’ll have to > keep our CI up-to-date regardless. Jon is already doing a great job > staying on top of things and adding EOL dates to dockerfiles as > comments to make it obvious when things can get dropped from Cirrus. > Also, I’m obviously I’m in favor of this proposal. :wink: > The “everything that passes CI is fair game” approach not only makes > sure we naturally catch up to new C++ features eventually (which is > the main motivation), but we can also steadily modernize our CMake > scaffold, Python scripts, and so on. -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Cluster Controller Framework Thoughts
Hi Vlad, thanks for the feedback, that's quite helpful. I'll dig a bit into some of your points below. As a general point, there's nothing wrong with chosing a different deployment model than whatever becomes the new default. Quite the opposite: Part of the thinking here has been that there's no single approach that'll work for everybody, hence we want to offer multiple layers that people can hook into depending on their needs and expertise. The Controller would be the highest level abstraction that gives you an experience not too far from current ZeekControl (more on that below). On the other end of the spectrum, skipping everything altogether and going with a manual systemd config is the lowest-level way of doing it. In between those two we have: using the Supervisor API through a custom Zeek management script (i.e., no Cluster Agent/Controller), and writing a custom controller to interface with the Agent API while doing your own state management. > Ultimately, given the choice between systemd + supervisor versus just > systemd, for our use case, just systemd gave us some distinct benefits and > reduced complexity. Ack, I can see that for you guys, especially with the current state of things. I'll just add here that (1) not everybody can/want to use systemd, so we'll need to have ways to build clusters in other settings; and (2) some of the technical advantages you mention should be addressable with the Supervisor/Controller, too; that's just not there yet (e.g., nicer process visualization). > it feels like I'm left with a choice between one orchestration tool + > the cluster controller framework, versus just using a single > orchestration tool to keep these files in sync and handle cluster > stop/start/restarts. I think part of the question here is how much effort one is willing to invest into installing and maintaining Zeek. If you (1) are very familiar with Zeek, and (2) have a current orchestration tool in place that's easy to extend with all the necessary pieces (incl. managing of restarts, logging, health monitoring), I agree that one tool sounds better than two. However, if we look at it from the perspective of a new user who wants to get Zeek running on their network quickly, figuring out all those pieces is probably quite a hurdle. That trade-off seems similar to ZeekControl today: people already have the option to go through systemd, but ZeekControl remains the standard way to run Zeek, even with all its quirks. Re/ putting files in place everywhere: Per the design doc, I definitely see distribution of packages and site-specific scripts in scope for future versions of the Controller. That would then leave people with the task to just install the same Zeek version everywhere, which seems a reasonable expectation to me. > If I need to reboot a system in a cluster, and it's running the manager and > logger, I'd like to see another system in the cluster get promoted to being > the manager and logger, and all the nodes to start talking to that instead. I would like to see that, too. :-) However, this seems to be quite a different thing than the systemd approach you are describing. How would such a dynamic scheme operate without some kind of control layer in between doing the coordination? In some future version, the Cluster Controller would be the management component that can initiate changes like dynamic fall-over. We can argue about whether that control layer should be a central component (as the Controller proposes) vs some distributed consensus scheme; and also whether we should really implement this ourselves or rather go with some 3rd party tool for coordination. But either way, I think something needs to be there. > it feels a bit like the Cluster Controller framework is trying to take > the old zeekctl features and get them to fit into a new model. The proposal for the Supervisor/Controller model has been out for a while, and the main point of feedback so far has been from folks who wanted to ensure that we don't loose functionality that ZeekControl offers today. So yes, that has been a starting point for fleshing out a bunch of this: Can we retain what people like about ZeekControl, but move it over into a new architecture that removes what they don't like (e.g., copying binaries around)--and all that while facilitating a more dynamic future world that increases Zeek's flexibility and resilience. I'm not saying that the current Controller design achieves all that already, but it has indeed been designed as an incremental path forward rather than a lets-redo-it-from-scratch approach. Happy to discuss if that's the right trade-off. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into packages
On Mon, Aug 31, 2020 at 10:57 -0700, Christian Kreibich wrote: > ... if we strengthen the notion of packages from the core distribution, we > may want to ensure zkg can be available from the outset Yeah, I'd be in favor of tying zkg more closely to Zeek itself so that it's always available as a required dependency. I think that also makes sense more generally as it has become a key part of our ecosystem. We can add it to auxil/ as another submodule. The Zeek-side can then use the code to get get packages in place directly, either through the command-line client or through the zkg Python API. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into packages
To summarize this a bit, below is what I think what I heard so far. Feel free to respond further, I'll move this over into the ticket later once we have consensus. Robin - General preference to keep packages in individual repositories hosted inside a new GitHub organization "zeek-packages". - Management through a meta-package that lists lists all desired packages as dependencies. The meta-package can version content by pinning packages to blessed versions. - Tie these meta-packages to the current Zeek releases. To take this a bit further: - I imagine this means that we'll have three meta-packages at any point of time: "zeek-packages-current", "zeek-packages-lts", and "zeek-package-devel". When a new release comes out, these rotate through. - People can install packages for older (now unsupported) Zeek versions by picking a older version of the corresponding meta-package. - The Zeek distribution can either download the current version of the meta package on install; or even just include the full content somehow (also see "zkg" below). - Testing - Need to make tests standalone and less dependent on Zeek versions. - Should make standard btest infrastructure available to tests (e.g., Zeek's btest helpers, pcaps). - Provide integration tests that execute across the full set of "zeek-packages". - Development - Make it it easy to work multiple packages at once (e.g., to update baseline; get all dependencies in place) - Documentation - Use Zeekygen to document the full content of a meta package at once; can host either on docs.zeek.org or packages.zeek.org. - Make it easy to autogen docs for individual packages (ideas: GitHub Pages through Vlad's cookie-cutter; autogen on packages.zeek.org) - zkg: - Distinguish standard/recommended packages from others. - Could we add a way to "prime" zkg's package cache so that a Zeek distribution could distribute a snapshot of "zeek-packages" for direct use; but zkg would still pull in updates if online access is available? ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into packages
On Mon, Aug 24, 2020 at 14:15 -0700, Jon Siwek wrote: > * What's the LTS policy for packages? Good question. I think would tie it to the Zeek LTS policy, with a "blessed" version of the meta-package that we recommend (and maintain) for each currently maintained Zeek version. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into packages
On Mon, Aug 24, 2020 at 11:49 -0700, Johanna Amann wrote: > This, from my point of view, it would be neat to have a way to still > easily install a rather large set of packages (potentially nearly > everything that is in policy at the moment) and run test on them. While I agree that integration testing is useful, too, ideally the new packages would primarily rely on tests that are standalone. Do you see a problem with that for, e.g., the SSL functionality? > that change a lot of the test baselines - especially when we touch > something that affects connection-ID hashing, or the order of elements > in hashmaps. Agree with Jon here: This might be an opportunity to make the tests less fragile, more like what we'd recommend for external packages anyways. > It would be nice if, afterwards, it would still be possible to install a > working set of a script for the running version of Zeek. Yeah, if we worked with a meta-package, we could "bless" a specific version of that for a given Zeek release. People could update further, but with less of a guarantee, though we'd try hard to ensure they work with different versions, can even CI them against a bunch of recent releases. Overall, our current policy/ scripts haven't required version-specific changes very often, so I'm not too worried here. The most common use case it probably some script starting to use a newly introduced feature, and that's pretty easy to catch / guard against. > It would be neat to have a place that contains the combined > documentation of these scripts. Agree, and I'd extend that to packages in general, you be a job for an extended packages.zeek.org to provide autogen'ed documentation. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Moving policy scripts into packages
On Mon, Aug 24, 2020 at 11:26 -0500, Michael Dopheide wrote: > I like (2) for cleanliness. Vote counted! > there should be an easy way to distinguish them from other packages > when doing a 'zkg list'. Good point. Also, one additional thought: Jon reminded me that zkg can manage dependencies already. So the "collection" I mentioned could be a meta-package that depends on all the ones we want. We might need to make that a bit more explicit for this use case (like you say for example in the output of "list"), but the basic functionality is there. Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Moving policy scripts into packages
Looking for some thoughts here. One of the items on the roadmap for 4.0 is moving scripts that currently live in policy/ over into Zeek packages. The goals here are to (1) facilitate maintaining & testing them independently of Zeek releases; and (2) come to a more flexible notion of "default scripts" that can incorporate community-maintained packages as well. This is tracked by issue https://github.com/zeek/zeek/issues/414, including a 1st pass over the existing policy scripts to understand what should/can be moved. (Thanks, Vlad!) Before we can begin working on this, we need to figure out how to organize this new world. One particular question is where the moved packages will live. I see the following options so far: 1. Move each into a a separate repository on the zeek/ GitHub account. 2. Similar, but to avoid cluttering zeek/, create a new GitHub organization "zeek-packages". 3. Put them all into a single mono-repository (e.g., zeek/standard-packages), i.e., treat them a one package. 4. Do (1) or (2), and additionally create "zeek-standard-packages" that's full of submodules pointing to them (and also to community packages). 5. Do (1) or (2), and teach zkg to understand "collections" of packages that can be installed/managed as a group, defined through some meta data somewhere. Along with all of this comes a question of how to make it easy for people to install a set of default packages now that these won't come with Zeek itself anymore. Some of the schemes above make that easier than others. Thoughts/opinions/more ideas? Robin -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
[Zeek-Dev] Re: Discussion: the guidance we want to give to package authors on the tags they assign
Sounds good to me, unifying tags makes sense. The one thing I'd add is a selection of standardized tags for general categorization, along the lines of the existing: https://docs.zeek.org/projects/package-manager/en/stable/package.html#suggested-tags Probably best to start with extending that section with the guidelines you propose before approaching package authors with individual PRs. That way, there'll be something to point them to. Robin On Mon, Aug 17, 2020 at 17:14 -, Duffy OCraven wrote: > I want to start a discussion here of the guidance we want to give to package > authors on the tags they assign in zkg.meta, to ensure people have a chance > to chime in, and we start-out with the benefit of multi-perspective group > process, so we reach for the best result. > > My proposal is just to articulate principles for good tag selection, to rein > in the existing scattershot we've seen so far, by giving the authors guidance > on what we want to see. I think we need to do this, to counteract that nearly > everyone takes their guidance from what they see the people before them have > done. If bad habits occurred and are allowed to persist, people will > dutifully adopt those bad habits. > > I posit that: the ideal set of tags will provide matches with queries of the > form: "Has a plugin for X already been coded?" And also matches with some of > the relevant queries for: "What other plugins have been coded for aspect Y?" > Find the words by filling in the sentences: "I implemented X." and "I > implemented an instance of Y." For Y, use the plural (indicators, scanners, > scripts) except when only the singular makes sense. > > Use the hyphen where punctuation is needed. Never use underscore. > > Don't add "analyzer" nor "protocol" nor "plugin" as a suffix. > > Don't mention bro or zeek. These are all Bro/zeek analyzers and plugins. > > The ideal set of tags can also include one that is perhaps unique to this > package (but not four or five that are unique to this package). This is as a > moniker, so that saying "go look at fizzamajig" should lead, by following the > fizzamajig tag, to what you intended the listener to see. > > Conversely avoid banal tags. If you write a piece of software, nonetheless > "a", "piece", "of", and "software" are all bad tags. > > Capital letters should be a rarity, i.e. in DoS because dos to many eyes, > immediately connotes a pre-Windows Microsoft operating system. att is fine > punctuated that way, and PostgreSQL and all the CVE are reasonable to > capitalize. SSL, TLS, TCP, PKI, UPnP, and EternalBlue are stalking-horses, to > consider, while we reach consensus, whether we are better off just > lowercasing where the capitalization is not essential. If in doubt, just use > alllowercase. Tags function quite well in alllowercase, and that is what most > people have done. > > If anyone uses the hyphen-form for a word, then everyone shall use the > hyphen-form for consistency. It does often increase readability, and is a > small price for the increase of understanding in the portion of our community > which it benefits. > > Anyone who disagrees with any of these details, PLEASE do chime in as I only > seek that we we reach for the best result, not that we we reach for my idea > of what the best result is. > > Anyone who has additional heuristics of goodness to add, also chime in with > them. We'll probably, after consensus, enact change by sending some PRs to a > few packages to unify them more. I did a sort of census last evening. Of 273 > tags used, I would banish 51 of them, and revise the punctuation or > capitalization of 15 others. > - Duffy O'Craven > ___ > zeek-dev mailing list -- zeek-dev@lists.zeek.org > To unsubscribe send an email to zeek-dev-le...@lists.zeek.org -- Robin Sommer * Corelight, Inc. * ro...@corelight.com * www.corelight.com ___ zeek-dev mailing list -- zeek-dev@lists.zeek.org To unsubscribe send an email to zeek-dev-le...@lists.zeek.org
