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.
Oh this is a good one I forgot. If my kid is playing Roblox and runs out of time, it goes into that screen loop and is impossible to resolve without at least killing Roblox, and sometimes rebooting the silly machine. That's pretty frustrating for the kid for sure, I ended up just whitelisting Roblox so it never happened.
Thanks for the background, there definitely seems to be a lot of clunkiness, and as someone who just started using it for IG, I have not experienced these but will keep an eye out. On a side note, I am always surprised how many products clearly haven't been used by the people making them...
I tried using Screen Time to manage my daughter’s use of my old MBPro, and eventually gave up – for the reasons you list. The issues were just so crippling and obvious that it felt abandoned to me.
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.
No, I was just surprised - I don't know anything about NetBSD (nor pkgsrc for that matter), but I worked with FreeBSD some 15 years ago and there were plans to move to SVN even back then. A quick search told me that the switch was completed in 2008 (a little bit after I left, begrudgingly, for Linux).
What challenges are there in switching to another VCS? Is the difficulty coming from the need to preserve history, or the need to re-evaluate workflows around the repo, or something else entirely?
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 immediately ran into an annoying issue, which is having the need to specify those directories manually. So I did, and the configure finished successfully when I ran:
actions.c: In function ‘verb_flag’:
actions.c:53:3: error: implicit declaration of function ‘strlcat’; did you mean ‘strncat’? [-Werror=implicit-function-declaration]
53 | strlcat(pkgtools_flags, "v", 1);
| ^~~~~~~
| strncat
Which tells me that I could fix it by providing `-I/usr/include/bsd/` and `-lbsd` or the like. I will give it a go. Any ideas anyway?
Edit: I added the above, and it went on to:
In function ‘strncpy’,
inlined from ‘read_repos’ at fsops.c:133:6:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error: ‘__builtin_strncpy’ specified bound 8192 equals destination size [-Werror=stringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This does not sound too good, you probably want to fix it (along with the other warnings on Linux). In any case, I got rid of `-Werror` and I have a couple of undefined references. I will most likely get it to work, but you see my issue here, right? Is it the "official" way to compile it from source by the way?
Edit #2: I got a working binary by making those changes[1]. Last few lines:
CCLD pkgin
/usr/bin/ld: external/pkgin-var.o: in function `var_get':
/tmp/pkgin/external/var.c:99: warning: This function cannot be safely ported, use getline(3) instead, as it is supported by GNU and POSIX.1-2008.
make[1]: Leaving directory '/tmp/pkgin'
---
You might want to look into compiling it on Linux, because without those changes[1], you cannot do it. I was using commit e963d1e1a2409ed51d191d936b5f75e35bdf9197, version 20.12.1.
[1] You also have to include `<bsd/string.h>` for `strlcpy` on Linux. Only `actions.c` is affected.
---
If you want, I am willing to send you an e-mail with the diff, but I will fix the other warnings, too, then. Oh, and instead of relying on `libbsd`, one could just add `strlcpy` and the like themselves.
---
By the way, from where do I get the `repositories.conf` exactly? The supplied `repositories.conf` seems outdated. I tried using both `ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/5.1/All` and `http://mirror-master.dragonflybsd.org/packages/$arch/DragonF...`, but they were not working.
Hmm, I tried to use a working one, but I got this:
processing remote summary (https://pkgsrc.joyent.com/packages/Linux/el7/trunk/x86_64/All)...
SSL support disabled
SSL support disabled
SSL support disabled
pkgin: Could not fetch https://pkgsrc.joyent.com/packages/Linux/el7/trunk/x86_64/All/pkg_summary.gz
I am currently using `file://` that points to the manually downloaded `pkg_summary.gz`. Not sure why SSL support is disabled when I configured it, it specifically asked for it, and I provided it through `--with-openssl=/usr/` and it passed because it found it.
I fixed it. I had to compile libfetch with `-DWITH_SSL'.
---
All in all, there are many problems that I ran into, but nothing that much of a big deal.
---
There is one problem I cannot seem to fix:
pkg_add: unable to verify signature: Signature key id 4735b9a256aaacaf not found
I keep getting this, and I have no clue how to change it or where it came from. Without this, nothing actually gets installed, so I cannot use pkgin or pkg_* until this is resolved. Do you have any clue? I tried to look for anything to change in pkg_install.conf or mk.conf but to no avail. Any ideas?
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."
That's the argument for autotools, but I wholeheartedly disagree. Untested code can be assumed not to work, so if a build script doesn't work on a certain platform, what's the likelihood that the C program it's building will work on that platform? When you see a poorly-written autoconf script checking for basic things like size_t, you have to wonder if the program it's building really supports pre-ANSI C. This wastes real time on not-so-uncommon platforms like Cygwin and MSYS2, where spawning subshells is slow and running ./configure can take minutes.
So if you've never tested your program on a platform where /bin/sh doesn't understand local, feel free to use local in the build script. Bashisms like local are safer anyway. Variable scoping is good. (Though I guess the author's claim of it working in a 70s era Bourne shell is still wrong.)
> This wastes real time on not-so-uncommon platforms like Cygwin and MSYS2, where spawning subshells is slow and running ./configure can take minutes.
That's true, but in my case it turned out to be insignificant. While changing all the autoconf junk in > 100 plugins could move the total build time from 50 minutes down to 40, I'd need an order of magnitude decrease in build time to warrant the work. I say order of magnitude because its only at a 5 minute build time that the entire dev process would see a paradigm shift-- at that point I could, with a straight face, stop shipping Linux binaries and just suggest that users compile the software themselves. (Of course that's not great usability for a whole class of Ubuntu users, but at build time == 5 minutes some other dev could easily come along and package things up with ease.)
Also, the extra wasted time under Windows isn't the fault of autoconf. Try doing `git any_subcommand` in msys2 and you'll get latency so high you'd think it were a practical joke.
I don't care about some spherical-cow ideal of portability. It has its own costs -- like autotools. This is why OP makes no mention of POSIX or portability.
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 ;)
That's good to know, actually. Thanks! Sorry about my tone before. Are there any other platforms that actually benefit from autotools, that you're aware of?
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.
> 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.
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 ;)