NovoLabs | Dallas, TX | Full-time | Onsite or REMOTE
NovoLabs is a small team focusing on Conversational Commerce in the Restaurant Industry. Our vision is to provide a world class product that allows users to transition from an analogue channel like a Phone or Drive Thru to digital channel.
We're 18 months old and have recently begun taking Transactions from well known restaurants!
As we are still small, we are looking for highly capable, high impact, deep generalists or expert level React / Graphql people.
Our current stack includes: Clojure, React, Graphql, Scala, Finagle, Google Cloud, Kubernetes, Postgresql.
We offer a highly competitive package and would love to hear from you! If you're interested please email me with any questions: Jeff.Davis@novolabs.com
I've been jumping between AWS and Google Cloud ( with a bit of Digital Ocean sprinkled in ) for the last several years. I chose Google as our cloud platform when we founded our company last August. I could War and Peace a bunch of things but that article does a very nice job in the details. Instead, I'll give a one liner:
AWS is to Linux as Google Cloud is to FreeBSD. "Rock solid performance and everything is exactly where you think it should be"
I'm happy for the guys at Bouyant, they've been great to work with in the past.
There's a very large complexity payment inherent in the new "cloud native" architectures that fundamentally isn't worth it for a large swath of use cases. Conduit, at first glance, appears like it might solve a large portion of it. If there's anything the last 10 years have shown us as an industry, it's that convention and programmer ease of use are the most important qualities of a new framework or way of working.
Rails / Go / K8S dominating Mesos / Containers over Jails / Maven over ANT / on and on. ActiveRecord is great, and Rails routing is great. Together they are magical for what they provide a user. Envoy is great. Istio is great. But there isn't a simplistic way to unify them even though for 95% of the industry it appears their functionality should go hand in hand.
Nokona gloves are almost comically well made. I've used mine for over 20 years at this point and outside of a once a year oil'ing it has held up remarkably well. My dad has his from the early 60's and while it looks worn ( he hasn't taken care of it ) it's still very usable.
Alan Jacobs has a pithy overview of Morton, and the following is taken from a recent post on Morton by him:
This strategy of employing familiar language in unfamiliar contexts gives the appearance of being radical but may not be quite that. It strikes me as being largely a reversal of Skinnerian behaviorism: the behaviorists said that human beings are nothing special because they're just like animals and plants, responding to stimuli in law-governed ways; now the object-oriented ontologists say that human beings are nothing special because animals and plants (and hammers and black holes) all possess the traits of consciousness and desire that we have traditionally believed to be distinctive to us. The goal of the philosophical redescription seems to be the same: to dethrone humanity, to get us to stop thinking of ourselves as sitting at the pinnacle of the Great Chain of Being.
It's hard for me to take Morton too seriously because our ( by which I mean his and mine ) Metaphysics are so diametrically opposed. Hyperobjects are so ontologically complex as to give the feeling they have been invented solely to justify the philosopher's pre-existing beliefs ( though in fairness, you can write that about a lot of things ).
I'm going to write a thing that I'm not sure I totally believe, but I'm going to try it on for size. Pls feel free to push back on any part, or give feedback on whether anything resonates with you:
I don't think you give enough credit to the potential importance of eloquent memes and the building of new religions of sorts, in pursuit of making the more complex truths about our world and humanity (which hopefully can inform desired common futures) more palletable to a sizeable majority. (My underlying assumption is that we are emotional machines that sometimes engage in rational thought, and not vice versa.)
Pure rationalism won't get us to the future we deserve. We need to treat our packages of beliefs almost as we do the most widely-used open source projects -- shiny surfaces, perhaps built collaboratively, that package up a more meticulously considered core, rooted in something that tends toward a more just world -- a surface thing that is perhaps a little more superficial and concealing of it's unique working, but can be interrogated and dissected by those who care to dive in. The rest can just consume it and have a shallow affinity for the beautiful packaging, and that's ok. The point is that we together build the core carefully, we can all interrogate it to understand why it does what it does, and why it points us in certain directions without asking us to go all the way down the rabbit hole, and that those who care to question its tenets can dig deeper into them.
So in this analogy, might Morton just we working on the pretty UI, that's trying to package up the underlying architecture in a way (if not with 100% fidelity) that can at least be more socially transformative ? It's this line of thinking that makes me feel your criticism to be, while not untrue, then at least somewhat counterproductive to the sorts of action/memes that I believe will be most effective in the world.
On the one hand, I viscerally agree with you because I have some distaste for some aspects of philosophy. On the other hand, we have terms of art in CS that seem equally obscure to outsiders. Have you ever looked at the complexity theory wiki?
Wait, there's a wiki on complexity theory? Computational complexity or the complex systems kind?
I don't find the term as obscure as a I find it offensive: it just sounds wrong. But yeah, there are plenty of terms like that in any field, whether they be obscure or just irksome.
Well what you have is a metaphysics of the logos, of rationality. That metaphysics is 400 years old and is already responsible for geoengineering the planet, and not geoengineering in some good way but geoengineering in the most reckless way you could think possible. It's also responsible for countless other global scale experiments which have been shown to wreak havoc on the planet. Surely it's evident that your metaphysics is deeply problematic now, wait until it's even more problematic as the amount of power we possess grows. The other metaphysics, that of animals and nature, that has a history of millions of years and usually works for millions of years until some catastrophe. The only really good thing about the logos is the potential power to prevent that sort of catastrophe, but also the power to cause exponentially more extinction events on shorter time scales. Possibly even our own. I would say that your metaphysics is totally untested and experimental, where as in the metaphysics of rest of life and dealing with nature of on its terms is time tested and therefore more true.
"the behaviorists said that human beings are nothing special because they're just like animals and plants, responding to stimuli in law-governed ways; now the object-oriented ontologists say that human beings are nothing special because animals and plants (and hammers and black holes) all possess the traits of consciousness and desire that we have traditionally believed to be distinctive to us. The goal of the philosophical redescription seems to be the same: to dethrone humanity, to get us to stop thinking of ourselves as sitting at the pinnacle of the Great Chain of Being."
"Almost all hackers subscribe to the mechanistic, materialistic ontology of science (this is in practice true even of most of the minority with contrary religious theories). In this view, people are biological machines — consciousness is an interesting and valuable epiphenomenon, but mind is implemented in machinery which is not fundamentally different in information-processing capacity from computers.
"Hackers tend to take this a step further and argue that the difference between a substrate of CHON atoms and water and a substrate of silicon and metal is a relatively unimportant one; what matters, what makes a thing ‘alive’, is information and richness of pattern. This is animism from the flip side; it implies that humans and computers and dolphins and rocks are all machines exhibiting a continuum of modes of ‘consciousness’ according to their information-processing capacity.
"Because hackers accept that a human machine can have intentions, it is therefore easy for them to ascribe consciousness and intention to other complex patterned systems such as computers. If consciousness is mechanical, it is neither more or less absurd to say that 'The program wants to go into an infinite loop' than it is to say that 'I want to go eat some chocolate' — and even defensible to say that 'The stone, once dropped, wants to move towards the center of the earth'."
That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them.
The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vast tree of Makefile's allowing you to create custom builds of virtually any software imaginable.
While pkg is still raw on the edges, I VASTLY prefer it to Debian's hodgepodge of package management tools that all do 90% of the other, though none of them do it cleanly and none of them have straightforward interfaces. Am I using dpkg here? What about aptitude? Or should I just roll w/ apt-get? All of these tools combine the ease of use of git with the flexibility of a Maven build. If you know how to use to descend deep into the depths of git or Maven, this isn't an issue ( and for the author, it certainly is not ). Yet there are numerous simple tasks ( like say, searching for a package remotely when you aren't sure the exact name ) which still require hitting up google and settling in for a Click-Your-Way-To-Adventure session.
PKG, in contrast, is both simplistic and flexible ( it reminds me of a industrial grade version of Brew in some sense ). It's a tool that I find myself integrating into my workflow beyond simple installs / updates, particularly it's seamless integration with jails. Configuration of remote repositories is vastly simplified as well.
PKG is not perfect by an means - it definitely has worts that need to be taken care of. I'm also sure that PKG probably feels a tad inadequte to some hard core sys admins - pkg has the look and feel of a tool designed by a programmer looking to handle normal cases than a tool designed to provide a sys admin with an atom bomb if necessary. Yet the system is still relatively new and as the bugs continue to get ironed out it's a reminder to me of why I love FreeBSD in a lot of ways - the abstraction point is flawless and it gets out of my way.
I really like that FreeBSD has binary package management. I started my journey into Unix almost 10 years ago with FreeBSD Unleashed.
I am considering writing a comparison command-to-command of apt-get vs. pkg, and differences in behavior.
* Are packages from the FreeBSD repos pinned the same way Ubuntu packages are, relase to release? Are there multiple repos (comparable to universe/multiverse, updates/backports)?
And so on. If I knew exactly how FreeBSD's pkg system worked related to apt-get, I'd be more comfortable going there full time. I'm also interested in how it integrates with Jails, should I just look in the Handbook for more info, or do you have a blog I should read on it?
I want to add that the FreeBSD ports management team is probably too small to handle complicated release management and backporting schemes like you see with RHEL or Ubuntu. That said, nothing stops you from doing it if you wanted. You can set up your own binary package repository using Poudriere. That's what I do; I tend to update everything quarterly unless there's a serious security flaw in something.
Right now, there's only a single package repository for each major FreeBSD release. The ABI doesn't normally change within major releases, so packages built on FreeBSD 10.0 will work on FreeBSD 10.1 (and vice verse).
A pkgng repository can contain older versions of packages, but "/latest" is tree of symlinks to the most recent versions in the repo.
The FreeBSD Ports Tree isn't tagged, so there's nothing equivalent to updates or backports. Sometimes, that means packages won't build on older (or newer) versions of FreeBSD, or it means that the ports infrastructure as a whole won't work properly once you go more than a few releases back. The FTP archive keeps copies of binary packages included with past FreeBSD releases (all the way back to 1.0). Generally, that means everyone using the latest version of Firefox from ports on FreeBSD 9.x, 10.x, and 11.x are going to be running Firefox 35.0.1_1,1. The ports maintainer might include FreeBSD release-specific patches in the package build scripts to handle any differences among currently (or formerly) supported FreeBSD releases.
I don't remember what universe or multiverse contain. If those are the ones that have stuff separated out based on the software package's licensing, ports/pkgng includes logic to handle EULA acceptance for non-free stuff. You can also configure it to _not_ accept a license, in which case packages that use a rejected license will fail to build.
Regarding jails, please see "man pkg". You can give pkgng a jail name or ID, and it will automatically connect to that jail to perform whatever task you asked of it.
apt-get update == pkg update ("man pkg-update"), usually unnecessary
apt-get upgrade == pkg upgrade ("man pkg-upgrade"), automatically updates the repo metadata by default
dpkg-reconfigure does not have an equivalent on FreeBSD. FreeBSD in general takes a default-deny stance on things, so post-package setup usually has to be handled by the sysadmin. There are a few packages that do some interactive post-install setup, but I personally consider this a huge bug (e.g., mail/postfix). Port maintainers generally display post-install setup instructions instead. You can read these via "pkg info". I use the Salt configuration management system, personally.
As for documentation, the FreeBSD Handbook or manual pages are always the first places you should look. There's also some info about pkgng on the wiki, but it's pretty dated as at this point, all of that stuff has been merged into FreeBSD.
Interesting, I'll have to test some of the features to see how they stack up.
In ubuntu, main = FOSS supported by Canonical, restricted = non-FOSS supported by Canonical, universe = community FOSS, multiverse = community non-FOSS.
Those usually don't get updated or messed with except for security. There is also the backports repo for package updates for stable releases.
The short version is that, as I understand it, the FreeBSD Foundation does release engineering different than Canonical or SPI, largely for historical reasons, and that as an end user, you would periodically run "freebsd-update cron" or subscribe to "freebsd-announc@freebsd.org" to check for updates to FreeBSD itself or run "pkg upgrade" to check for updates to third-party packages. It's really, really simple compared to the "good" old days of cvsup and "make world" and roughly equivalent to "apt-get upgrade" or even "apt-get dist-upgrade" (or their YUM analogues).
The FreeBSD equivalent of "main" would be FreeBSD itself, with source/binary updates via freebsd-update or source updates via Subversion. The FreeBSD Ports infrastructure handles package building for _all_ third-party software (Xorg, GNOME, KDE, Emacs, Perl, etc.), which would be the equivalent of "universe" and "multiverse". The Ports infrastructure has integrated license auditing (see https://raw.githubusercontent.com/freebsd/freebsd-ports/mast... and https://raw.githubusercontent.com/freebsd/freebsd-ports/mast...), which allows you to accept or reject licenses at package build time.
There is no equivalent to "restricted". The binary package repository maintained by the FreeBSD Foundation itself only contains free software, meaning that it includes only software whose licenses allow (a) redistribution of the original sources (like an FTP mirror), (b) selling copies of the original sources (like on CD-ROM), (c) free redistribution of the binary package (e.g., via FTP), (d) selling of the binary package (e.g., via CD-ROM), and (e) automatic license acceptance (which would exclude software like dccd that have EULAs which must be accepted prior to compilation/installation).
There is no equivalent to "backports" or "security". Supported FreeBSD releases get regular bugfixes and security updates as described above. As FreeBSD is a volunteer effort, there just aren't enough people involved to make maintaining alternate ports trees feasible. The ports tree does get frozen and tagged at each FreeBSD release to facilitate package building, CD-ROM manufacturing, and FTP distribution, but those tags aren't maintained except as historical markers. If you want security updates, you need to stay abreast of the latest commits the ports tree (whether via portsnap [source], subversion [source], or pkgng [binary]).
> Right now, there's only a single package repository for each major FreeBSD release. The ABI doesn't normally change within major releases, so packages built on FreeBSD 10.0 will work on FreeBSD 10.1 (and vice verse).
And it's worth pointing out that the per-branch repositories are all built from the same sources — ports is not branched. The only reason to have separate release-branched binary repositories is for ABI bumps between stable releases.
For at least as long as I've been using it (7+), FreeBSD has always had binary and source packages. Ports are still very much existent and supported (and needed if you want anything custom).
All pkg replaces is the old way of getting/managing binary packages (pkg_add, pkg_delete, pkg_info, etc).
You're 100% correct. Sorry about that, my fingers didn't translate what I had in my head in regards to pkgng replacing the old separate multi-component way of handling binary packages.
My understanding was that pkgng is a architectural overhaul in addition to a simple client clean-up - configuration is different for example. What I was trying to get to was that the newer design is barely two years old in production. I should have written this more clearly and did not, thanks and sorry.
Do you know of a non-broken way to build ports with many dependencies? This has always been my biggest annoyance and one of the things that constantly made me pick the cough other BSD. Whenever something that I need isn't in the package set, all hell breaks loose: most ports seem to have most options turned on by default (generating a lot of dependencies) and there seems to be no easy way to select configuration options prior to starting the whole build process -- so I end up having to sit for the next two hours, pampering the build process and tuning (actually, mostly disabling) options every time it moves on to the next port. Needless to say, this isn't fun, especially since there's no easy way to tell what dependencies an option is going to pull (I remember being able to retrieve that information through a script I cobbled up but...).
I could probably script it to just go ahead with the default dependencies, but that gives terrible results (I try to install this little console tool and now it's pulling gnome-something-something because the console tool can be integrated with ImageMagick and that's compiled with support for this-weird-format which is provided by this-weird-lib which is part of the Gnome project and now I'm slowly compiling half the packages in Gnome even though I don't use a single program from the Gnome project).
Add OPTIONS_UNSET=gnome to /etc/make.conf, plus whatever other options you want excluded system-wide. Ditto OPTIONS_SET. You can override for specific ports with ${PORTNAME}_SET/_UNSET too.
When I have to do it manually, I usually build ports with -DBATCH=yes because I trust the defaults. The config-recursive target is a good one to know, but if I have to tweak package build settings, nowadays I'll set the appropriate OptionsNG knobs ahead of time in /etc/make.conf.
(I rarely install directly from ports, though. Instead, I use Poudriere to make my own package repository, and I have a version of make.conf set up for Poudriere that includes all of my package configuration tweaks.)
pkgng + poudriere = my sysadmin sweet spot. I can customize package builds to my heart's content while continuing to use the FreeBSD package repositories (if I want). It'd be nice if pkgng would build stuff from the ports tree if necessary, like MacPorts does, but frankly pkgng is good enough as is. If I need more than FreeBSD's binary package set, I'm comfortable with building directly from ports (in case of one-offs) or expanding my Poudriere deployment. Compared to pkg_install/portupgrade/portmaster, pkgng is awesome---flawless binary upgrades, even from my custom package repository. Compared to YUM/APT, pkgng is still awesome---setting up a custom repository and automating package builds is pretty easy, especially compared to Spacewalk (which I want to like, I really do).
Scala is much closer in spirit to ML / OCaml / Haskell than a LISP dialect, but I do agree w/ you that Scala rocks. It's my favorite language I've picked up since O-Caml.
Man that's a bad post about Scala. Scala has a lot to love and a bunch to hate within the language itself, but writer doesn't appear to have the ability to actually discuss it.
Scala doesn't have operator overloading btw. It just doesn't restrict method names very much. This is very different from how C++ treats operators as special cases.
If you give your methods bad names, it really is not the language's fault. You can probably find a way to make a bad API even if you are limited to a-zA-Z0-9 ...
If a library has an inscrutable set of method names blame the lib not the language.
I know that, and I use the term only because the author did. I agree that it's the fault of library designers not on the core language, but it is still a legitimate issue to raise.
Fortunately it's feedback that the community has taken to heart. 2.11 should improve compile times, as will new incremental compilation features in SBT 0.13. IntelliJ's Scala support has gotten much better recently and the official Scala plugin for Eclipse has also made major strides. (Though I still use vim)
Odersky has taken an official stance against symbolic method names, especially in libraries, and many of the most famous offenders (Dispatch's absurd periodic table) are rightly ridiculed within the Scala community.
I don't have anything to add on implicits. They've certainly tripped me up a few times but generally it's just a matter of finding the right import, though I have been cursing Play's implicit JsValueWrapper the last few days.
That's good to know. I haven't used Dispatch since 2011 when I first started using Scala (that was a rough introduction). I'm looking forward to Play moving their WS package out of the core though—right now we've basically written a few wrappers around AHC in their style for the pure Akka parts of our stack but we'd love to standardize.
NovoLabs is a small team focusing on Conversational Commerce in the Restaurant Industry. Our vision is to provide a world class product that allows users to transition from an analogue channel like a Phone or Drive Thru to digital channel.
We're 18 months old and have recently begun taking Transactions from well known restaurants!
As we are still small, we are looking for highly capable, high impact, deep generalists or expert level React / Graphql people.
Our current stack includes: Clojure, React, Graphql, Scala, Finagle, Google Cloud, Kubernetes, Postgresql.
We offer a highly competitive package and would love to hear from you! If you're interested please email me with any questions: Jeff.Davis@novolabs.com