jperkin · HackerTrans

jperkin

no profile record

Submissions

Mac OS X pkgsrc binary packages now following a rolling release model

twitter.com

3 pointsby jperkinhace 10 años0 comments

Pkgsrc-2015Q3 packages for illumos and OS X now available

mail-index.netbsd.org

2 pointsby jperkinhace 11 años0 comments

Pkgsrc-2015Q2 packages for OS X now available

mail-index.netbsd.org

9 pointsby jperkinhace 11 años1 comments

Pkgsrc-2015Q1 packages for OS X now available

mail-index.netbsd.org

49 pointsby jperkinhace 11 años14 comments

Pkgsrc-2014Q4 packages for OS X now available

mail-index.netbsd.org

2 pointsby jperkinhace 11 años0 comments

Building packages at scale

perkin.org.uk

19 pointsby jperkinhace 12 años5 comments

Pkgsrc-2014Q2: 11,000+ binary packages for SmartOS, illumos, Mac OS X, and Linux

mail-index.netbsd.org

7 pointsby jperkinhace 12 años0 comments

10,000 binary packages for OS X

pkgsrc.org

2 pointsby jperkinhace 13 años0 comments

A node.js-powered 8-bit CPU

perkin.org.uk

1 pointsby jperkinhace 13 años0 comments

9000 up-to-date binary packages for OS X

perkin.org.uk

28 pointsby jperkinhace 13 años13 comments

7,000 binary packages for OSX Lion

perkin.org.uk

2 pointsby jperkinhace 14 años0 comments

Tweaking the SmartOS global zone

perkin.org.uk

2 pointsby jperkinhace 14 años0 comments

comments

el mes pasadodiscuss

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

hace 12 mesesdiscuss

> 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 ;)

hace 2 añosdiscuss

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.

hace 5 añosdiscuss

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.

hace 5 añosdiscuss

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.

hace 5 añosdiscuss

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

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

hace 9 añosdiscuss

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

It wouldn't work on Solaris 9 and older either as the original /bin/sh also doesn't support "local", but as those releases are EOL it's fine to discount them.

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 ;)

hace 9 añosdiscuss

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."

hace 9 añosdiscuss

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.

hace 9 añosdiscuss

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.

hace 10 añosdiscuss

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.

hace 10 añosdiscuss

> 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/

hace 10 añosdiscuss

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

along with a bunch of pre-packaged modules:

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

Let me know if anything you need is missing and I'll add it.

hace 10 añosdiscuss

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/

hace 11 añosdiscuss

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.

hace 11 añosdiscuss

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.

hace 11 añosdiscuss

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 update the 32-bit repository tomorrow.

hace 11 añosdiscuss

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.

hace 11 añosdiscuss

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.

hace 11 añosdiscuss

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.