jperkin

It's still a thing: https://pkgsrc.smartos.org/install-on-macos/

Took them 3 months before a "we're not interested" email was sent. No reasons, either.

Yeh this is really really tough. They have an excellent RFD that explains the hiring process and it contains a section on this here: https://rfd.shared.oxide.computer/rfd/0003#_rejection_of_non...

I ported their Hubris kernel to RISC-V and ARMv6 before applying for a role to work on it, so thought I had reasonably strong materials, but got rejected.

I fully understand and empathise with their reasons for not providing feedback, but it does mean you're left not knowing whether you were a hair's breadth away from getting in but were behind a better candidate and it would be worth trying again in the future, or rejected for other reasons that no improvement in materials will make up for. As a fully signed-up member of imposter syndrome club I'll obviously lean towards the latter ;)

For me it's completely unfit for purpose:

* It's incompatible with some apps, e.g. Roblox, that are full-screened, and you end up in an annoying loop between the Roblox screen and the request more time screen fighting with each other, with no ability to click anything. My kid has learned how to hit the Option-Command-Escape shortcut to force-kill Roblox using just the keyboard and restart.

* Sometimes Screen Time requests come via Notifications (yay), and sometimes they come via Messages (boo). There doesn't appear to be any logic behind which.

* When they come in via Messages, and I leave Messages.app running for too long, it ends up eating all of the memory on my 32GB M1 Max and forcing me to restart the system.

* Sometimes requests do not come through at all.

* Sometimes the user cannot request more time. Clicking the button does nothing.

* Sometimes multiple requests come through for the same app. Approving one of the requests does not satisfy all of them, you have to approve all of them.

* Requests for websites do not work. Every so often Roblox breaks and results in having to re-download the .dmg. You end up in a loop between approving the request for more time and the website saying the user needs to request more time. I ended up writing a shell script to curl it instead (which requires munging User-Agent because the Roblox download page does not have a direct link to the dmg).

It's clear there are no Apple employees who actually use Screen Time to manage kids time. I can only assume they just let their kids have unlimited access, because trying to actually use Screen Time is absolutely infuriating, and only gets worse over time (e.g. the Notifications vs Messages thing is a recent regression).

It's also worth pointing out that I have absolutely zero issues with Android Family Link. It all Just Works for similar purposes.

The repository of record is CVS, but you can - like many of us do - use either the hg export (https://anonhg.netbsd.org/pkgsrc) or GitHub (https://github.com/netbsd/pkgsrc) instead.

At some point we will transition the repository of record to something else, but it's being done carefully. We want to do it right, and there aren't many volunteers willing help with the work.

I am the pkgin maintainer, and would be interested to hear about any issues you have building pkgin. It should build on any of the 23 platforms that pkgsrc supports, including Linux.

I even offer daily binary package builds for CentOS here: https://pkgsrc.joyent.com/install-on-linux/

Feel free to open up an issue at https://github.com/NetBSDfr/pkgin/issues and we can take a look.

macOS users may want to use my binary package repository, updated every few days from pkgsrc trunk:

https://pkgsrc.joyent.com/install-on-osx/

Any OS which use the Korn shell as /bin/sh, for example Solaris 10, 11, and illumos:

  $ /bin/sh -c "fail() { local f; }; fail"
  /bin/sh[1]: local: not found [No such file or directory]
  $ /bin/sh --version
    version         sh (AT&T Research) 93t+ 2010-03-05
  $ uname -rsv
  SunOS 5.11 joyent_20160721T174127Z

Whether you regard these platforms as extant depends on your point of view. Most people wouldn't, and that's fine. We'd naturally disagree ;)

It also uses the "local" keyword, which is non-portable.

People like to bash the autotools, but they exist for exactly this reason - they already spent decades working through all these gritty details to ensure the scripts generated are portable. To paraphrase Spencer "Those who do not understand autotools are doomed to re-invent them, poorly."

For me it's a relatively trivial reason: my muscle memory has been trained over the years that cmd-[1-9] switches tabs, and there's no way to configure that in Terminal.app (last time I checked) without unstable SIMBL plugins.

MySQL is a great example of it working. Hundreds of employees, the vast majority remote, regardless of where they were located. Sold for $1B.

It was my first remote job and I enjoyed it immensely, so much so that I haven't had an office job in 10 years now, and have no desire to return to one.

I switched from building from quarterly branches to trunk a while ago, so those packages are actually updated with the very latest every few days.

At the moment, the best I can find for OS X is Rudix. The selection of available software is pathetic compared to Homebrew and Nix, but a lot of the core stuff is there and it's all packaged as a .pkg, which makes it really easy to cleanly erase installed software.

Apologies for hijacking a Nix thread, but I'd love your views on our OS X binary package sets[0]. We currently ship over 14,000 pre-built signed packages, all self-contained under /opt/pkg, and easy to search/install/remove using pkgin which has a familiar feel to anyone used to apt-get/yum/etc.

The packages are continuously built from pkgsrc trunk so should be reasonably up-to-date, and we try to be responsive when users need newer versions or packages built with different options.

So far the feedback has been positive, but I'd love to see more use-cases so we can improve the experience for everybody. Thanks.

[0] https://pkgsrc.joyent.com/install-on-osx/

They're all available:

    $ pkgin se python3
    python35-3.5.1nb2    Interpreted, interactive, object-oriented programming language
    python34-3.4.4       Interpreted, interactive, object-oriented programming language
    python33-3.3.6nb3    Interpreted, interactive, object-oriented programming language

    $ pkgin avail | grep ^py3 | wc -l
        1412

Not true any longer, at least for the binary packages I produce[0]. I switched them over to trunk-based builds a while ago, which are updated every few days.

[0] https://pkgsrc.joyent.com/install-on-osx/

Cross-compilation is sometimes an option, but not necessarily a good one.

It is usually a significantly manual process (I now have to download and install an OS which is supported by the runtime and build a cross-compiler for my target platform, which may or may not even be possible, or even work), isn't always supported by the runtime, usually requires changes to the build procedure, often requires special patches - and at the end of all that users are still left with either having to repeat all this themselves, or trust someone else's binary bootstrap.

Compared to a simple, portable, C-based bootstrap where any user can type 'make' and ensure provenance directly from source. For what gain?

Uninformed? Perhaps. I haven't designed and written my own language, and I'm certainly no expert. I'm just someone who gets asked to port these new languages to platforms which aren't Linux or OSX, and it's a lot of hard work. I just know that if I did it write my own it would look a lot more like perl/python/lua than ghc or go from a build perspective.

Trust is certainly one of the issues when languages migrate to requiring themselves to bootstrap.

However, by far the most infuriating (and one I run into frequently in my line of work, hence the anger) is when you are trying to get the language running on a platform for which binary bootstraps do not yet exist.

Portability matters. If you want your language to be useful and available to as many people as possible, why would you seek to artificially limit the number of platforms it can be built on, just so you can avoid writing the bootstrap in C? I'm sure there is some amount of pride on the part of the language author when their language can bootstrap itself, but it certainly isn't a pragmatic decision.

It's especially frustrating when the bootstrap requirement itself changes so that only very recent versions of the language are sufficient (e.g. GHC), leaving the porter to have to reach back into the archives and carefully plot a path through building multiple versions from the original C-based bootstrap until they finally get to master.

This is painful, painful work, and then has to be done all over again for e.g. 32-bit vs 64-bit. It doesn't have to be like this.

Just to follow up on this, these are now available in the 64-bit repository:

    $ pkgin se nodejs
    nodejs-0.12.2        V8 JavaScript for clients and servers
    nodejs-0.10.38       V8 JavaScript for clients and servers

I'll fix that, and add nodejs-0.12 too. 0.10.36 was current at the time that pkgsrc-2015Q1 was frozen for release, but I can build them from our separate pkgsrc-joyent repository.

Thanks for the heads up.

The main general benefit of pkgsrc is that it's cross-platform and, having been around since 1997, now runs on 22 different operating systems.

This means that rather than having to run Homebrew or MacPorts on OS X, rpm or apt on Linux, ports on FreeBSD, dports on DragonFly, cyg-apt on Cygwin, .. - you get the idea - you could instead just run pkgsrc across all of them, and only have to worry about one set of tools and only have to update one software repository. pkgsrc will happily run as an unprivileged user in your home directory if you just want to compliment the system package manager.

For OS X specifically, we provide this binary package repository to make it very easy for people to get started. pkgin has a very familiar interface for people used to other binary package managers, so after a couple of commands to install the tools you can start installing from 11,000+ binary packages quickly and easily.

For developers there is a lot that pkgsrc offers in terms of aiding portability, and due to the large number of supported platforms a lot of infrastructure to support them, but that is a whole topic by itself.

Reversing the question, I don't see that Homebrew or Macports have many benefits over pkgsrc, other than Homebrew is arguably easier to write new packages for (if you know ruby), and Macports has more packages. However I will be glad to admit I'm no expert on either of them, so if there are other advantages please tell me so we can take a look at improving feature parity.

Not sure why someone has edited the title, the point of posting this release specifically (we release every quarter) was that the binary packages are now signed by default - an important requirement these days - and I wanted to emphasise that.

Anyway, enjoy! Happy to answer any questions.

pkgsrc is our primary package manager for SmartOS, our illumos distribution. We also provide binary packages for OS X and Linux:

http://pkgsrc.joyent.com/

pkgsrc should still work on Solaris 10, and there are a few people in the community continuing to provide patches for it, but obviously a lot of us have moved onto illumos so the support and documentation isn't going to be as good. That said, the aim of pkgsrc is to support every system possible, so we will always welcome contributions.

Manta objects are effectively just files stored on ZFS, so you write anything you like. Maybe this example session will help:

* Perform a directory listing of a tmp directory in my public area. mls(1) is the ls(1) equivalent for listing Manta directories.

  $ mls -l /jperkin/public/tmp
  -rwxr-xr-x 1 jperkin        540751 Oct 23 14:19 bbc.png
  -rwxr-xr-x 1 jperkin         27237 Dec 13  2013 libreoffice.tar.gz
  -rwxr-xr-x 1 jperkin        132079 Oct 25 02:01 lx64.png
  -rwxr-xr-x 1 jperkin       2397256 Jul 09  2013 nas-workdir.tar.gz
  -rwxr-xr-x 1 jperkin       1626181 Jul 10  2013 nas-workdir64.tar.gz

  $ mlogin /jperkin/public/tmp/bbc.png
   * created interactive job -- f1a2e579-34f8-4dd4-da19-db33954a0772
   * waiting for session... | established
  jperkin@manta #

  jperkin@manta # uname -a
  SunOS 0ae1c6ec-d47a-455c-9dd6-97eec16da31b 5.11 joyent_20140628T000418Z i86pc i386 i86pc Solaris

  jperkin@manta # ls -l /manta/jperkin/public/tmp/bbc.png
  -rw-r--r-- 1 root root 540751 Nov  7 11:41 /manta/jperkin/public/tmp/bbc.png

  jperkin@manta # file /manta/jperkin/public/tmp/bbc.png
  /manta/jperkin/public/tmp/bbc.png: PNG image data, 1680 x 940, 8-bit/color RGBA, non-interlaced

  jperkin@manta # find /manta
  /manta
  /manta/jperkin
  /manta/jperkin/public
  /manta/jperkin/public/tmp
  /manta/jperkin/public/tmp/bbc.png

  jperkin@manta # convert /manta/jperkin/public/tmp/bbc.png /var/tmp/bbc.jpg

  jperkin@manta # ls -l /var/tmp/bbc.jpg
  -rw-r--r-- 1 root root 504004 Nov  7 11:46 /var/tmp/bbc.jpg

  jperkin@manta # mput -f /var/tmp/bbc.jpg /jperkin/public/tmp/
  /jperkin/public/tmp/bbc.jpg    [======================================================>] 100% 492.19KB

Of course this is a simple and contrived example, the real power of Manta comes when you have say 1,000,000 log files stored under a particular path and want to grep them all for a particular string. To do that you'd do something like:

  $ mfind /jperkin/public/logs -n "access_log.*.gz" | mjob create -o -m "gzcat" -m "grep something" -r "cat"

Briefly:

* Between Solaris 10 and Solaris 11, Oracle bought Sun and killed the open source efforts known as OpenSolaris. illumos started from the final open source bits of what eventually became Solaris 11 and has now significantly diverged. Solaris is effectively dead, illumos is very much alive.

* There are a number of illumos "forks", of which SmartOS is ours, but all forks still share the common illumos code (we merge daily) and contribute heavily back to the common base. Each fork may contain features which aren't yet ready for merging back, e.g. our work to port KVM[1] to SmartOS is not part of illumos yet, but other distributions such as OmniOS[2] have taken that work and integrated it.

* SmartOS is a minimal distribution, we have removed a lot of parts (desktop, shared storage, etc.) which do not fit in with our explicit design goals, and added tooling around virtualisation. You boot from USB/CD/PXE into a minimal live-image hypervisor known as the Global Zone[3], and then perform work in zones which are backed by local storage. To upgrade, you simply replace the USB image with a newer platform and reboot into the new live image.

* As for software, we provide userland built from pkgsrc[4], which gives you access to over 13,000 packages available under /opt/local, allowing you to use both the SmartOS tools as well as any third party software you may need (e.g. GNU stuff). There is even full desktop stuff provided, should you want to use it[5].

* In Manta, when running a job you are basically running in a zone with as many pkgsrc packages pre-installed as we can manage (currently nearly 9,000), so the chances are that the software you need is available. If not, you can easily build it yourself and the store it back in Manta to use later as an asset[6] for your jobs.

* There is definitely a free tier for Joyent zones (search for "free" on https://www.joyent.com/products/public-cloud/pricing), I thought there was also an additional free tier for Manta but I can't see it right now, however it will only cost a few cents to do some basic tests in Manta and get a feel for what it can do.

I primarily work on pkgsrc, but I know a number of other engineers will be reading this thread and can comment in more depth on SDC/Manta, so feel free to ask any more questions or pop onto #smartos or #manta on Freenode IRC.

Thanks.

[1] http://dtrace.org/blogs/bmc/2011/08/15/kvm-on-illumos/

[2] http://omnios.omniti.com/

[3] http://www.perkin.org.uk/posts/smartos-and-the-global-zone.h...

[4] http://pkgsrc.joyent.com/

[5] https://twitter.com/jperkin/status/348506063336783872

[6] https://apidocs.joyent.com/manta/jobs-reference.html#assets-...

I want to try ccache at some point (with pkgsrc it's trivial to add), but I'm not convinced it will help.

Given the distributed nature the first implementation would keep the ccache objects on NFS, and that's going to cause additional latency for every cc invocation to the point where even a cache hit will likely be slower.

The next step would be to synchronise all of the ccache objects back to each build zone and then loopback-mount the directory into each chroot. This may provide a small increase in performance, but at the cost of additional complexity. I also wonder whether it would be enough of a performance win compared to the extra time it will take to rsync the objects to each build zone at the start of the build.

I will likely do this at some point anyway, as I'd like to have some hard numbers to back up my theory, and if it turns out to be a win, even better ;)

I work on pkgsrc which is another alternative. Its main advantages are:

* A large number of pre-built binary packages with an apt-get style command (pkgin) to install them. Over 10,000 packages are available for OSX in the most recent release (2014Q1).

* It is cross-platform to over 20 different platforms. At Joyent we provide binary packages for SmartOS/illumos, OSX, and Linux, so you can use identical packaging tools across multiple platforms, rather than having to use different tools on each OS. It is the default package manager on SmartOS, with over 12,000 binary packages available for that platform.

* As the 'src' in 'pkgsrc' implies, it's very easy to build from source too if you want to tweak build options or compiler flags. You can also install into any prefix you desire (we default to /usr/pkg), even as an unprivileged user to your home directory.

Our binary packages are available from http://pkgsrc.joyent.com/installing.html and we'd love to hear feedback on how to improve them or adding support for different platforms.

Huh, yes, they appear to have coincidentally fixed it since I wrote that comment. Maybe I need to start reporting all GitHub bugs as Hacker News comments...

Their language detection is indeed terrible. I have a repository (https://github.com/jperkin/pilights) which is entirely composed of shell scripts and a single markdown README. GitHub's analysis?

  Perl 83.5%	  Shell 16.5%

A number of my other repositories have similar problems, but this one is by far the worst.

I already have a blog post on that ;)

http://www.perkin.org.uk/posts/creating-local-smartos-packag...

You'll just need to tweak paths from /opt/local (SmartOS) to /usr/pkg (OSX).

The one caveat is that multiple repository support in pkgin is not great right now. It should be ok as long as your site-specific packages are separate from the rest, and have unique names etc. This is something we hope will be fixed during this year's GSOC.

Hi Chris!

So yeh, it's not quite as simple as Homebrew, which is definitely optimised for that use-case, but it's still relatively straight-forward.

Taking the 'tmux' package as an example:

https://github.com/jsonn/pkgsrc/tree/trunk/misc/tmux

The main guts are in Makefile. DESCR is a few lines of description about the package, and is used by package managers. distinfo contains SHA1 and sizes of the source tarballs and patches. PLIST is a list of files the package will install. And finally, the patches/ directory contains per-file patches which will be applied to the source prior to building.

Due to the cross-platform support, there is a huge range of functionality available for Makefiles, and so some of them can look pretty complicated.

However, it's pretty straight-forward to get started, and there are various tools (e.g. pkgtools/url2pkg) which can make things pretty simple to get started.

I'm planning an introductory blog post on this at some point which should hopefully cover all of the basics.

Hi!

Briefly, pkgsrc is quite similar to both, in that it allows you to build software easily from source.

This repository is a bulk build of all available packages in pkgsrc, so it gives you the option to install from binary packages instead of having to compile them from source. However, you still have the option to build from source if you prefer, or want to select different compile options from the defaults.

It also comes with 'pkgin' which is very similar to 'apt-get' and allows you to quickly search, install, upgrade and remove binary packages.

This is the same framework we use for SmartOS, so if you provision a SmartMachine from Joyent you get the same interface. pkgsrc is cross-platform, so you can use it on Linux, OSX, Solaris, *BSD .. or even more exotic systems such as Cygwin or Haiku.

If you have any comments/complaints I'd love to hear them, we want to provide excellent packages.