mpasternacki

I'm a bit surprised nobody mentioned qmail yet: https://cr.yp.to/qmail.html

I think 10.3 has an older version of i915, this has worked on vanilla, but 11 has already Linux 3.7 or 3.8 DRM imported which breaks with thunderbolt display, and it was fixed in drm-next-4.7 patch (which is going to land on HEAD someday, but it might not be backported to 11).

Looks nice, thanks!

Not in HEAD, but https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree... is stable in my experience

Author here. Debugging dual boot is interesting, debugging virtualbox is not. And I was curious if I can get it running. I just was too lazy to figure it out, I found a more interesting problem to work on. In the end, I stayed in the native FreeBSD install, so there was no motivation to figure out the custom kernel in virtualbox (it is quite simple in bhyve, though)

It doesn't work yet with GELI as far as I know, so for encrypted root /boot still needs to be on a separate partition. There was some work to support encrypted /boot, I'm not sure where it stands now, but I'd be very surprised if it supported encrypted ZFS.

I’m author of that gist (just noticed I have some comments there I need to reply to), still running the setup, now with FreeBSD 12-CURRENT. Tl;dr it generally works, still no wi-fi support. X works fine (running with drm-next-4.7 patches to get external thunderbolt display to work; vanilla kernel works fine with built-in and DVI display, gets confused by Thunderbolt display only). Gave up on pkg because I want to control my build flags, I’m using portmaster now and thinking about setting up poudriere on a bigger server. Feel free to ask if you have any particular questions.

Not necessarily, they might have just generated revokation certs which are separate (so that they can be used in case your private key is lost). Keeping a revokation cert would be a responsible thing to do, just in case something like this happens.

If you have a text version, at least preprocessing and proposing changes could be doable (especially that as far as I know, formal French is quite uniform - but then, it's what I heard from others, all French I actually know comes from a Dexter's Laboratory episode). In Poland, though, the original acts are published as PDFs, and the text extraction itself needs assistance, if it's even possible without OCR: the international agreements that are side-by-side in multiple languages (Polish, other party, sometimes also English) are usually image scans saved as PDFs.

There are services (external, secondary to the published acts) that published a re-unified, highlighted version. I would imagine a repository that maintains a current unified text, with the "update acts" as commit messages (or even with the original PDFs somehow linked to the commits. I'm sure it can be implemented somehow in Git plumbing. Annotations, maybe?). I'd even pay for this kind of service - but probably not as much as lawyers who need it for their daily work pay for the existing equivalents.

Is this account actually maintained by Bundestag (or other actual piece of state administration), or is it just a mirror? Also, either German law is really mature and stable, or this repository is unmaintained: last commit oin master is Jan 2013.

I'd love to see such a repository for the acts in my country, by the way, but the official source is a PDF, and most of the published acts are actually patches to existing (already heavily "patched"), like "In the section II, item 13a, change words 'foo and bar' to 'foo, baz and quux'". This mess untangled into an actual, highlighted, unified text is an actual product, and lawyers happily pay the subscription. I imagine it is similar in other countries.

Huh. Doesn't the fact that Pirate Party's and Independence Party's results are well within each other's confidence intervals make it a tie?

I don't think that beginning your question with "I cannot begin to imagine how fucktarded you'd need to be to do this" is going to encourage people to answer that question…

That aside, my approach with Linux/Docker is to have a "fat" host system that is open to the outside world, terminates SSL, load balances and proxies the containers' services (nginx), and provides global services are either shared between containers (Postfix smarthosting to Sendgrid, DNS cache, rsyslog), or services that can manage user/service isolation well enough on their own (PostgreSQL). Containers run mostly applications, or services that I need in multiple instances or versions.

I do containerize Redis, as it can't be safely shared across multiple services (no privilege isolation, too easy for one service to DoS the other with a blocking operation), but then I don't consider Redis to be a database – it's rather a "shared state server", kind of a more sophisticated memcached.

However, I understand the approach of CoreOS, which minimizes role of the host OS. In this model, host's only role is to support containers, and every other process needs to be containerized. From this point of view, Postgres is an application. This way, I can flexibly run multiple version of Postgres, try to upgrade it without needing to set up separate host service, and so on. Personally, I wouldn't feel comfortable with that, but I understand how it could be useful.

Regarding storage performance, database's data directory would need to be a volume anyway (to be able to upgrade database without trowing away the data). A volume is just a `mount --bind`, without any aufs layers, to any point of the filesystem, so it doesn't seem to me that i/o performance hit would be noticeable…

Thanks for taking care of that! Please let me know if your legal team finds anything wrong. If you need to contact me, either open a GitHub issue on the repo, or email me (maciej at 3ofcoins dot net).

There's also a WordPress plugin called "Jetpack". Both are so different areas, that I don't think it matters much. If it happens that either project is actually bothered by mine and reaches out to me, I'll be happy to talk.

I've checked for name conflicts in related areas, in package repositories (FreeBSD ports, Debian's and Ubuntu's archives), major open source hosting services, and haven't found anything related. Let me know if I missed anything relevant.

VPS seems to require VIMAGE, which currently is a no-go for me (I experience kernel panic on boot if I compile it in), and the second link… well… the tinfoil hat of the author's blog has to be impressive. I've tried to read this and some other rants (they pop up quite high in search results), and couldn't find any actual content or any sources for the statements.

Capsicum and rctl are definitely on my list of things to look into (especially capsicum, it seems to be enabled in the GENERIC kernel configuration).

You are not expected to parse 'docker ps' output programatically.

I see that my particular pet peeve (there's no name or link information in `docker inspect`) has been fixed. Nice! Still, I can't imagine the thought process that leads to express links in JSON as `["/foo:/bar/foo","/baz:/bar/baz"]` rather than `{"foo":"foo","baz":"baz"}` (or even `{"/bar/foo":"/foo","/bar/baz":"/baz"}` if you're attached to the weird hierarchical names). I similarly cannot imagine reasoning that leads to providing port number in JSON as a string, with prefix.

> Is it still Docker's official position that CLI is only official interface, and using HTTP API is frowned upon? That was never true. I'm not sure how you got that idea.

Cannot find it now: it's not easy to google out (and if it was in the docs, I'd need to go through web.archive.org), and I didn't think about archiving it myself for later use. I think this was either in (possibly earlier version of) docs, or in some GitHub issue. The sentiment seems to stand, though: Docker's own code base doesn't even include any usable API client, and many seemingly basic CLI operations are very convoluted in API (how do I `docker run` with API? Is it still split across at least two separate calls?). Some of these problems are echoed in https://github.com/docker/docker/issues/7358

Some (possibly most of all - I certainly hope so!) are solved, but the API docs were good at listing the endpoints and (some of) the parameters [I recall JSON format was incompletely described, or not kept up to date]. There was virtually no pragmatic docs on how to use the API to achieve equivalent of, say, a `docker run` invocation. And while I obviously can open an issue or fix it in a PR, reflecting problems back at community because it's open source, if it bothers you, go fix it yourself doesn't seem a proper approach. In particular, if the problem is about keeping documentation in sync with code (format of JSON described in API docs did at some point diverge from actual behaviour; if you want me to go through the docs right now and verify each piece, I'd be happy to do that, but let's discuss the consulting contract first), it's not reasonable to expect your users to pinpoint the issue by going through Git changelogs.

You can use all these things [HTTP Auth] with the registry API.

Can I `docker pull` an image that is behind plain http auth (e.g. at a registry proxied to https://foo:bar@example.com/)? How do I specify that? Last time I tried to figure this out (before 1.2.0, after 1.0.0, so it may have changed), this was either not possible, or completely undocumented.

And while we're at it, what would exactly be the problem with letting me pull an image available at https://foo.bar@example.com/path/to/image.tar? Why there even is a separate registry API rather than plain HTTP? This part still eludes me.

Re tcp://… vs http://… it's obviously functionally equivalent and cosmetic, unless you want to write some plumbing and you have to add logic to translate from the tcp:// format (which doesn't seem to have any actual reason to be written this way) to http:// URL and back. Similar thing with `tcp://` prefix for ports forwarded from linked containers: I either have to use the long form that includes the original port number, or parse out the irrelevant `tcp://` piece (yes, I know there could be udp:// [but why the double slash? is there any URI path that could follow?]; the protocol is usually obvious from the context, and need to parse out the irrelevant text is actual overhead).

So, for Docker's convenience (or because of a bit of thoughtlessness when something was first implemented), there's a small but significant overhead incurred on a lot of current and future pieces of plumbing and containers, because for some reason (was there any?) you decided `tcp://` looks better than `http://` for an HTTP URL, and `tcp://1.2.3.4:567` looks prettier than just `1.2.3.4:567`.

Thanks for pointing that out! Post updated. Slackware was first distro I ever used seriously, after getting hooked up on Linux with a Red Hat 5.0 or 5.1 CD that was attached to a (printed) IT monthly newspaper. I have to tell, FreeBSD feels kind of similar to Slackware.

BTW, it's interesting that you chose to reply to "refrain from adding new features" part (which may have been unnecessary snark on my side), rather than to "stopping for a while to think" part (which is the actual point)…

It's less about particular features (none of these is individually harmful, but I personally find the monolithic architecture a bit of an issue), and more about taking time to actually define stable and complete APIs and boundaries. Stabilization (from technical reliability POV) is all good and fine, but - for instance - is there a way to easily find out containers' names and links, and exact forwarded ports, from the API without regexping `docker ps` output and "tcp/1234"-like strings that should be meant for human eyes only? Is it still Docker's official position that CLI is only official interface, and using HTTP API is frowned upon? Is all information about a container available in `docker inspect` or API equivalent, or do I still need to parse `docker ps` to find out about names and links? Does the registry/index mess ever going to go away, did it even make sense (other than vendor lock-in) at some point? Since Docker and registry API is HTTP, why can't I use http auth (even implemented by an nignx proxy) instead of certs (which are fairly new) or centralized index for authentication? It should be as simple as using `https://user:pass@IP/…` URLs, what's the problem with it? While we're at it, why on Earth is HTTP Docker endpoint specified as `tcp://IP:PORT` rather than `https://IP:PORT`, which would make it possible and easy to proxy, use http auth in an intuitive way, and generally reflect how it works rather than obscure it? Should I go on?

It doesn't need to be systemd, and that's the beauty of Rocket's design: it is composed of individual, well defined pieces with precise boundaries and areas of responsibility. As I wrote, my main practical concern now is to get something container-like working on FreeBSD. Docker is useless here unless it's wholly ported; Rocket is useful even if I don't use its code and go with (even partial) implementation of the spec.

From my practical POV, my options now are: port Docker (NOPE), reimplement Docker (NOPE GOD WHY), port Rocket (Maybe?), reuse spec and pieces of Rocket's code in my own opinionated NIH plumbing (Hell yeah, somebody did the thinking part for me! The spec is usable!), or write own opinionated NIH plumbing from scratch (why would I if there's a decent spec to lean on?).

What's interesing is that Docker used to run (almost) this way some time ago. I guess the daemonless mode won't fly with managing communication (iptables NAT, IP assignment, linked containers, etc).

What good is of updated documentation if change breaks my code? The good way would be to first define and stabilize interfaces, and work from there - but this would require stopping for a while to think, and refrain from adding new features in the meantime, which doesn't seem likely with Docker.

And while I don't support "revolution" (or even think that Rocket is necessarily better than Docker, or that Better One Should Win), I really appreciate break from monoculture. Having one large player in any area is harmful. Even if Rocket stays a niche project, its existence on the market will influence Docker's strategy.

Docker is not static. If much of it is implementation-defined, and implementation is evolving, then documenting a particular version of Docker is as valuable as I'd be willing to stay locked down to that particular version. And the APIs are not stable: just look at https://github.com/jenkinsci/docker-plugin/issues/115 to see how a Docker upgrade can break a project that uses its APIs (and if the plugin used CLI rather than HTTP API, it would still break: the cause was a change in formatting information that was not available anywhere in a parseable form, and as far as I know is still available only as "pretty text" to be parsed by a regexp)

Original ranter here, thanks :)

Regarding "trusting the datacenter": it was an overstatement, but while I can risk my own data, I am double-wary with my clients' data, and triple-wary with my clients' users' data. And while I don't assume that cloud provider is necessarily evil and unreliable, I need to survive losing a provider (be it because provider went bankrupt, or because I tried out GAE and got locked out in a Google Checkout mishap, or because of whatever reason), and I cannot rule out possibility of a leak (think Dropbox: hindsight's 20/20, but I don't believe I can predict which one of cloud storages will be next Dropbox). An extra bonus of good encryption is that I can spread storage over cheaper, but less reliable providers.

Your remark about ignoring network realities is good, thanks! I work mostly with cloud or remote servers, it's been at least 10 years since lat time I in the same room as a server I manage (and back then it was an office Samba file/print server). Maybe my perspective shows here, and it may be just as limiting as older tools just phrasing everything as "tapes" and "autochangers". I am closely looking at FreeBSD/ZFS right now, and this may not fit well with `zfs send`-based backups.

I'd be definitely interested in taking a closer look at Byteback! Since it's based on btrfs' snapshots, it may also work well with zfs (and may be exactly the plumbing I am about to write soon). If you manage to publish it, please let me know. Not sure if my email is listed on my HN profile: it's maciej at pasternacki dot net. Thanks!

This has been implemented for some traffic lights in Warsaw, and has one more bad side effect (possibly because of bad implementation): if you a bike in the late evening on the smaller street, that's configured "red unless there's a car that will be crossing" to maximize throughput of the bigger street, you have to wait for a car or use a pedestrian crossing, because the loops won't detect a bike.

Won't mdns / zeroconf / avahi / however it's called this week work for ad-hoc networks? It surely does the trick in LAN.

It won't work properly across routers, at least not out of the box (tried that when configuring Tinc VPN), but maybe this would be a good direction?

The issue here is not only the depth limit, but also:

* performance overhead of each layer, however small

* disk space for files removed in intermediate steps (scenario: ADD huge-ass source tarball, commit, RUN compile+install+remove, commit - user has still download the huge-ass source tarball to use the final image which doesn't have it)

* there's often just no need to publish intermediate layers; there may even be a good reason to not publish them (say, I distribute a program compiled with a proprietary compiler as a step of the build, but can't distribute the compiler itself)

* simplicity of having just one image for user to download and for publisher to distribute, rather than whole chain (this will be more important when we are able to use anything else than the registry to distribute images)

The main cost is less clarity: the build steps aren't isolated anymore, so it's harder to pinpoint issues. There's also obvious risk of my script not interpreting all options correctly.

Actually, I've just disabled VOLUME statement in the script, as it seems to be a no-op in Docker. Only trace it leaves in the image is setting image's command to '/bin/sh -c "#(nop) VOLUME [\"/data\"]"'.

I want to inherit from the base image, to keep the shared files actually shared. This is a feature. It's just the dozen layers of that inheritance that bothers me.