Hacker Newsnew | past | comments | ask | show | jobs | submit | dhon_'s commentslogin

As a parent with kids at three different schools, help keeping track of their schedules would be amazing.

Currently updates from the schools are spread over multiple sources: paper notes, email, sms, "news" and "calendar" in school app (which are not kept in sync), and Facebook. Different schools use different apps.

Additionally the channels are often noisy, with messages about groups my kids don't belong to, and "helpful tips" like how to pack healthy lunchboxes. These notifications come in during the day while I'm working, get dismissed due to the low SNR and then the useful ones often slip through unnoticed.

Definitely an area that is ripe for disruption, but as others here have commented, I don't feel confident about Google being the provider.


When I was a child, schools didn’t need to communicate on a daily, weekly (or even monthly) basis with parents. How times change. Heck, we went for a whole school day without having to talk to Mummy or Daddy. So this agent is technology to help the mess enabled by technology?

>multiple sources

how about when a kid has 7 classes, and each teacher says to just check the google doc within google classroom where they each type daily notes into unstructured tables that are each different for each class oh and parents dont actually have their own google classroom login they are just supposed to log into the kids account.

Also, family management is so *fundamentally broken* that it's disheartening and almost laughable that priority is ai over global acl management. There should not be a separate parental control dashboard for roblox, fortnite, instagram, tiktok, etc etc etc etc. Every app should be REQUIRED to expose all parental controls in a standard protocol upstream to identity management that is manageable by multiple management accounts in a family unit. I should be able to go into settings, click a kid, turn off chat for a child, and it instantly updates on my partners phone without needing an account at the service itself to manage it and knowing the ins and outs of how their parental controls are evolving weekly. Family settings should exist ABOVE any single user account and apply to all accounts to any service linked within the family.


Is copperhead related to this Copperbrain project?

https://github.com/deadbringer17/Copperbrain

They have similar names, seem to solve similar problems and both have first commit within a few days in July. One is Python and the other Typescript though and they don't seem to be forks.


ChatGPT based naming


I worry about the accumulating debt of maintaining all this "free" code if (once?) the subscription honeymoon ends.

Meanwhile I'm shipping tons of new features, upgrading outdated systems and delivering real value. But I do worry.


I'm waiting for the models to start responding with "Oh hi Simon!"


Language still matters because writing robust code in C requires discipline on many fronts, and LLMs will often do the minimum to get code running (as will most humans) unless prompted further. Rust protects you from some of these issues and gives you greater confidence that changes will not introduce bugs.


On hardware? Usually hardware issues or quirks are a bigger issue than memory honestly.


You can also push deployments to remote systems which is great for servers and headless devices like raspberry pis. I use colmena and deploy-rs on different projects because they have some nice features but you can also do it with bare nix.

I have a repo for kiosk appliances that can build an SD card image for a specific device in a fleet (so no on device configuration is required) but it can also push out updates or changes at runtime. NixOS isn't perfect for embedded devices yet but works well for cases like this in my experience.


If you are using an Apple Silicon laptop and you want to deploy to an x86-64 Linux box, this can get a bit annoying due needing to deal with cross compilation in nix.


The Make target I use to deploy in this manner (MacBook to x86-64, single machine) is simply:

    server:
        @echo "Deploying machine (with ssh-agent forwarding): '$(MACHINE)'"
        NIX_SSHOPTS="-A" \
        nix run nixpkgs#nixos-rebuild -- switch \
        --flake .#$(MACHINE) \
        --target-host $(MACHINE).$(DOMAIN) \
        --build-host $(MACHINE).$(DOMAIN) \
        --no-reexec \
        --verbose \
        --sudo

Which has been working well. I admit I do not understand what all of these flags do in detail.

This uses ssh agent forwarding, and then sudo via PAM. That allows for passwordless sudo. Building (well, activating) without sudo is pretty involved last I checked, I could not get it to work.


You can easily spin up a linux builder vm or I just have a dedicated remote builder on my network which I offload to


You can have an x86-64 remote builder, or use a service like nixbuild.net, rather than use cross-compilation.


What did-ger-eyes-doo?


Looking, just looking.


I have older versions of litellm installed on my system - it appears to be a dependency for aider-chat (at least on NixOS)


Cue a flood of crass jokes as the bots attempt to prove their humanity


In this case though, the new driver has the same license as the project it was based on and explicitly credits the original project

  ISC License
  
  Copyright (c) 2010-2022 Broadcom Corporation
  Copyright (c) brcmfmac-freebsd contributors
  
  Based on the Linux brcmfmac driver.


This surprised me - but sure enough, they're right. The linux brcmfmac driver is ISC licensed:

https://github.com/torvalds/linux/blob/master/drivers/net/wi...

// SPDX-License-Identifier: ISC


A lot of Linux kernel drivers are permissively licensed, or dual-licensed with a choice of GPL and a permissive license. This is especially common for vendor-developed drivers. From a hardware vendor’s perspective, broad license compatibility directly supports adoption: the more operating systems, hypervisors, and embedded environments that can incorporate the driver code, the wider the potential market for the hardware itself.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: