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

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

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

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

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

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

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.

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/

    $ 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

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

Comments URL: https://news.ycombinator.com/item?id=11666160

Points: 3

# Comments: 0

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.

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.

Comments URL: https://news.ycombinator.com/item?id=10373658

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=9903012

Points: 9

# Comments: 1

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