5 ms·

I’m curious how they plan to do continuous integration. The Apple hardware-only clause of the macOS SDK license agreement really crimps the options for CI, espe

I’m curious how they plan to do continuous integration. The Apple hardware-only clause of the macOS SDK license agreement really crimps the options for CI, especially for open source projects with limited budget. Travis is a godsend, but there are startup latency and capacity issues there even in the paid tier. Apple has made major contributions to open source, as evidenced by FoundationDB here, LLVM, WebKit, and other projects. But they no longer make servers, and the fallback — Mac mini — is on life support, which puts projects and service providers who need to treat macOS as a first-class target in a real bind. Even something limited like the IE Edge and Visual Studio images Microsoft provides would be a huge boost.

fnord123 8y ago
>I’m curious how they plan to do continuous integration. The Apple hardware-only clause of the macOS SDK license agreement really crimps the options for CI, especially for open source projects with limited budget. FoundationDB is a distributed key value store. These almost always run on servers. macOS is not a server OS. Is there any reason to build this on macOS, over, say, FreeBSD.
- jen20 8y ago
  Many developers want to install it for local development - presumably this is a particular popular sentiment _at Apple_. There is a FreeBSD port already, however [1]. [1]: https://www.freshports.org/databases/foundationdb/ https://www.freshports.org/databases/foundationdb/
  - Mister_Snuggles 8y ago
    Sadly, as I discovered today, the FreeBSD port is incomplete. First up, it doesn't create the fdb.cluster file. I reverse engineered that logic out of the Mac OS packaging script, which wasn't a big deal. Once I created the file I was able to start it up and connect to it with fdbcli. Second, the Python bindings do not work on FreeBSD. Trying to set the API version (the first step in calling the API) gives an error specifically saying they're not supported on FreeBSD. Still though, for something that was released two weeks ago to be already ported to FreeBSD is pretty impressive!
    - jen20 8y ago
      There has been a more complete pull request [1],[2] back to the main project repository which solves some of these problems, and should ultimately result in the (FreeBSD) port being fairly straightforward. [1]: https://github.com/apple/foundationdb/pull/309 https://github.com/apple/foundationdb/pull/309 [2]: https://forums.foundationdb.org/t/freebsd-support-for-foundationdb/357/3 https://forums.foundationdb.org/t/freebsd-support-for-founda...
  - fnord123 8y ago
    >Many developers want to install it for local development Why? Just use the in tree Dockerfile (which didn't work due to linking errors with libstdc++.a missing definitions for basic_istream::ignore last I checked).
    - hiroshi3110 8y ago
      Try release-5.1 branch. See https://github.com/apple/foundationdb/pull/263 https://github.com/apple/foundationdb/pull/263.
soperj 8y ago
lol to webkit. It was a fork of khtml.
- solarkraft 8y ago
  It is, but they improved and maintain it.
hb3b 8y ago
Is there a precedent for Apple enforcing this clause on providers in the CI space? I vaguely remember some cease-and-disist letters to Hackintosh vendors but I'd imagine that has to do with brand protection.
maccam94 8y ago
> they no longer make servers, and the fallback -- Mac Mini -- is on life support Well, there's also the Mac Pro (companies even make rack mounts that fit 2 machines in a 4U). But I wholeheartedly agree about the CI issues (having been hampered by them in a previous project). That doesn't really seem to be an issue for FoundationDB though?
wwilson 8y ago
The only license you need to accept to use this software is Apache 2, so I’m not sure where you’re getting the idea that there’s an Apple hardware restriction.
- ihnorton 8y ago
  The question is not about where FoundationDB can run in general. Sorry if that was unclear. The question is about (public?) continuous integration testing for changes to FDB against macOS specifically, eg for pull-requests (for example, to allow contributors to make changes targeting other platforms without needing to own a mac for local tests).
  - wwilson 8y ago
    Ah, sorry, that’s a good question. The good news is that FDB has a fairly opaque platform abstraction, and deterministic simulation tests for everything above it, so the vast majority of continuous testing in terms of CPU cycles can be run on Linux. The only thing that really needs to run on a Mac are tests for changes to the build or packaging system, or to the MacOS implementation of the platform layer. My sense is those changes are pretty rare. I don’t know whether the FDB team has an official recommendation for MacOS CI. I’d recommend posting a question on the forums: http://forums.foundationdb.org http://forums.foundationdb.org
  - bluejekyll 8y ago
    what's wrong with Travis? https://travis-ci.org/bluejekyll/foundationdb-rs/jobs/375032045 https://travis-ci.org/bluejekyll/foundationdb-rs/jobs/375032... I already set that up, it installs the binary for FoundationDB then runs the tests for our Rust client on mac. No reason why they couldn't do the same for FoundationDB, but I bet they have something in house.
deleted 8y ago
[deleted]
saagarjha 8y ago
The Swift project uses an array of Mac Pros: https://ci.swift.org/computer/ https://ci.swift.org/computer/

fnord123 8y ago

>I’m curious how they plan to do continuous integration. The Apple hardware-only clause of the macOS SDK license agreement really crimps the options for CI, especially for open source projects with limited budget. FoundationDB is a distributed key value store. These almost always run on servers. macOS is not a server OS. Is there any reason to build this on macOS, over, say, FreeBSD.

jen20 8y ago
Many developers want to install it for local development - presumably this is a particular popular sentiment _at Apple_. There is a FreeBSD port already, however [1]. [1]: https://www.freshports.org/databases/foundationdb/ https://www.freshports.org/databases/foundationdb/
- Mister_Snuggles 8y ago
  Sadly, as I discovered today, the FreeBSD port is incomplete. First up, it doesn't create the fdb.cluster file. I reverse engineered that logic out of the Mac OS packaging script, which wasn't a big deal. Once I created the file I was able to start it up and connect to it with fdbcli. Second, the Python bindings do not work on FreeBSD. Trying to set the API version (the first step in calling the API) gives an error specifically saying they're not supported on FreeBSD. Still though, for something that was released two weeks ago to be already ported to FreeBSD is pretty impressive!
  - jen20 8y ago
    There has been a more complete pull request [1],[2] back to the main project repository which solves some of these problems, and should ultimately result in the (FreeBSD) port being fairly straightforward. [1]: https://github.com/apple/foundationdb/pull/309 https://github.com/apple/foundationdb/pull/309 [2]: https://forums.foundationdb.org/t/freebsd-support-for-foundationdb/357/3 https://forums.foundationdb.org/t/freebsd-support-for-founda...
- fnord123 8y ago
  >Many developers want to install it for local development Why? Just use the in tree Dockerfile (which didn't work due to linking errors with libstdc++.a missing definitions for basic_istream::ignore last I checked).
  - hiroshi3110 8y ago
    Try release-5.1 branch. See https://github.com/apple/foundationdb/pull/263 https://github.com/apple/foundationdb/pull/263.

soperj 8y ago

lol to webkit. It was a fork of khtml.

solarkraft 8y ago
It is, but they improved and maintain it.

hb3b 8y ago

Is there a precedent for Apple enforcing this clause on providers in the CI space? I vaguely remember some cease-and-disist letters to Hackintosh vendors but I'd imagine that has to do with brand protection.

maccam94 8y ago

> they no longer make servers, and the fallback -- Mac Mini -- is on life support Well, there's also the Mac Pro (companies even make rack mounts that fit 2 machines in a 4U). But I wholeheartedly agree about the CI issues (having been hampered by them in a previous project). That doesn't really seem to be an issue for FoundationDB though?

wwilson 8y ago

The only license you need to accept to use this software is Apache 2, so I’m not sure where you’re getting the idea that there’s an Apple hardware restriction.

ihnorton 8y ago
The question is not about where FoundationDB can run in general. Sorry if that was unclear. The question is about (public?) continuous integration testing for changes to FDB against macOS specifically, eg for pull-requests (for example, to allow contributors to make changes targeting other platforms without needing to own a mac for local tests).
- wwilson 8y ago
  Ah, sorry, that’s a good question. The good news is that FDB has a fairly opaque platform abstraction, and deterministic simulation tests for everything above it, so the vast majority of continuous testing in terms of CPU cycles can be run on Linux. The only thing that really needs to run on a Mac are tests for changes to the build or packaging system, or to the MacOS implementation of the platform layer. My sense is those changes are pretty rare. I don’t know whether the FDB team has an official recommendation for MacOS CI. I’d recommend posting a question on the forums: http://forums.foundationdb.org http://forums.foundationdb.org
- bluejekyll 8y ago
  what's wrong with Travis? https://travis-ci.org/bluejekyll/foundationdb-rs/jobs/375032045 https://travis-ci.org/bluejekyll/foundationdb-rs/jobs/375032... I already set that up, it installs the binary for FoundationDB then runs the tests for our Rust client on mac. No reason why they couldn't do the same for FoundationDB, but I bet they have something in house.

deleted 8y ago

[deleted]

saagarjha 8y ago

The Swift project uses an array of Mac Pros: https://ci.swift.org/computer/ https://ci.swift.org/computer/