> We're very close to just being about to set an AI coding agent to brute-force a driver for anything.
This is false. To "brute force" a driver, you'd need a feedback loop between the hardware's output and the driver's input.
While, in theory, this is possible for some analog-digital traducers (e.g WI-FI radio), if the hardware is a human-interface system (joystick, monitor, mouse, speaker, etc.) you literally need a "human in the loop" to provide feedback.
Additionally, many edge-cases in driving hardware can irrevocably destroy it and even a domain-specific agent wouldn't have any physics context for the underlying risks.
Strictly speaking, I don't think we need a human to run repetitive tests. We just need the human to help with the physical parts of the testing jig.
For instance: A microphone (optionally: a calibrated microphone; extra-optionally: in an isolated anechoic chamber) is a simple way to get feedback back into the machine about the performance of a speaker. (Or, you know: Just use a 50-cent audio transformer and electrically feed the output of the amplifier portion of the [presumably active] speaker back into the machine in acoustic silence.)
And I don't have to stray too far into the world of imagination to notice that the hairy, custom Cartesian printer in the corner of the workshop quite clearly resembles a machine that can move a mouse over a surface in rather precise ways. (The worst that can happen is probably not as bad as many of us have seen when using printers in their intended way, since at least there's no heaters and molten plastic required. So what if it disassembles itself? That's nothing new.)
Whatever the testing jig consists of, the bot can write the software part of the tests, and the tests can run as repetitiously as they need to.
In practice, a "ban" consists of personal loan guarantees of a certain percentage thereby limiting the frequency and magnitude of this sort of financing.
Essentially, that means some amount of corporate risk is leveraged upon the principal investors.
This is common practice in the EU for so-called "club deals".
This is the best post to HN in quite some time. Kudos to the detailed and structured break-down.
If the author had a Ko-Fi they would've just earned $50 USD from me.
I've been thinking of making the leap away from JIRA and I concur on RDS, Terraform for IAC, and FaaS whenever possible. Google support is non-existent and I only recommend GC for pure compute. I hear good things about Big Table, but I've never used in in production.
I disagree on Slack usage aside from the postmortem automation. Slack is just gonna' be messy no matter what policies are put in place.
Anecdotally I've actually had pretty good interactions with GCP including fast turn arounds on bugs that couldn't possibly affect many other customers.
What do you use if not slack? OPs advice is standard best practice. Respect peoples time by not expecting immediate response, and use team or function based channels as much as possible.
Other options are email of course, and what, teams for instant messages?
I’ve always that forums are much better suited to corporate communications than email or chat.
Organized by topics, must be threaded, and default to asynchronous communications. You can still opt in to notifications, and history is well organized and preserved.
If you work in a team, email is limited to the people you cc: while a convo in a slack channel can have people you didn't think of jump in* with information.
See the other point in the article about discouraging one on one private messages and encouraging public discussion. That is the main reason.
* half a day later or days later if you do true async, but that's fine.
But - from the people you actually want to get to contribute - emails come with an expectation of a well thought out text. IMs ... less so.
I've been working across time zones via IM and email since ... ICQ.
I'm probably biased by that but I consider email the place for questions lists and long statuses with request for comments, and for info that I want retained somewhere. While IM is a transient medium where you throw a quickie question or statement or whine every couple hours - and check what everyone else is whining about.
I have now been roped into talking more about a topic I have no interest in and am completely ambivalent to… :/
But clearly, thats cultural.
If you keep your eyes on the linux kernel mailing you’ll see a lot of (on topic) short and informal messages flying in all directions.
If you keep your eyes on the emails from big tech CEOs that sometimes appear in court documents; you’ll see that the way they use email is the same way that I’d use slack or an instant messenger.
Thats likely because its the tool they have available- we have IM tools that connect us to people we need (inside the company)- making email the only place for long form content, which means its only perceived as being for long form content.
But when people have to use something federated more often, it does seem like email is actually used this way.
I get it, email accomplishes a lot. But it "feels" like a place these days for one-off group chats, especially for people from different organizations. Realtime chat has its places and can also step in to that email role within a team. All my opinion, none too strongly held.
We use self-hosted Mattermost (team version, i.e. without limits but no enterprise features like LDAP). Fine for a small team (around 40 active users here) where you can script account actions via the API, probably not fine when users become a lot more, or you might need access to the compliance functions for audit purposes, etc.
For us the free version of Slack was insufficient, the commercial one too expensive, and anyway, given that it's a cloud-based system, it's not compliant with our internal rules for confidential information (unless we can get some specific agreement with them). On the side, there is a bit too much analytics/telemetry in the Slack client.
not possible:
- workloads over 15m for lambda last time I checked, unsure on other providers
- if you are looking to do anything stateful
possible but not ideal/inconveniences:
- cold starts can hamper latency sensitive apps (language dependant + there are things you can do)
- if you have consistent traffic its not very good value for money
- if you value local debugging
Do you have any sources that support your claims that the risks and "remediation" are solved problems? Regardless of the content of the video I'm very curious if you have legitimate sources for how something like mesothelioma is a "solved problem", because I surely don't know any.
I've had clients in asbestos remediation (data science / management side), dealt with two personal real estate properties (one rural and one urban) that had asbestos issues, and grand parents on both sides of the family tree with black lung.
Mesothelioma is not "solved", but akin to pneumoconiosis and pulmonary fibrosis its risk profiles are well-known.
The risk profile is "exposed to asbestos" which - as the video correctly pointed out - was _never banned_ despite the well-known risks. It's a common misconception that asbestos was banned (because it seems like it should be) but it never was thanks to industry interests.
I don't think the author realizes the time*attention triage that happens when your sole corporate responsibility is to manage others. I've noticed a distinct personal trend in "email succinctness" the more people I need to manage.
That said, using good grammar is never a bad thing and depending on the subject matter and relationships between the respective communicators, short-hand can be both a deliberate obfuscation practice and social coding of the intimacy of the respective relationships.
The chosen propagation media (wire substitute) wouldn't have significant frequency responses differences for those lengths for that level of power in the audio frequency range.
You'd need to have transmission-line effects kick-in which would occur at higher frequencies and/or if a cross-section of the signal propagation paths would have a significant difference in impedance. All three of the chosen medium act like simple power-sink resistors in this scenario--attenuating the signal consistently across the power frequency spectra.
Seriously, just do a frequency sweep and plot the log of the output responses! But no, that would be far too straightforward an experiment.
What really matters is the signal source, any amplified distortion in the signal, final sonic transducer (speaker), transmission medium (air density), transducer orientation (for higher frequencies), and the individual listener's ear.
"However, the tester surmised that introducing the materials into the circuit is just like adding a resistor in series, and they’re unlikely to distort the audio too much, except by lowering the signal level."
It's really a terrible write-up (AI?), pure click bait.
The final sentence is just garbage:
"They then tried various materials like mud and banana, which, although they’re pretty poor conductors, still seemed to introduce imperceptible changes to the signal, at least for the average person."
This is also not true and hasn't been so for years. One can set a preference to "not recommend", but one can not explicitly block any channel.
Depending on your particular "preference constellation's weights" (over which you have no direct control), you can, in fact, be shown videos from that channel again.
I pay for plenty of other media (music, games, sports, comedy, books) and even do some Patreon for a few podcasts and YT channels, but I refuse to directly support a publishing monopoly that has had an actively user-hostile interface for over a decade.
I used to use Invidious but it was breaking too often. Nowadays, I just open YouTube in a private window, or use yt-dlp from time to time to watch something later offline.
This is false. To "brute force" a driver, you'd need a feedback loop between the hardware's output and the driver's input.
While, in theory, this is possible for some analog-digital traducers (e.g WI-FI radio), if the hardware is a human-interface system (joystick, monitor, mouse, speaker, etc.) you literally need a "human in the loop" to provide feedback.
Additionally, many edge-cases in driving hardware can irrevocably destroy it and even a domain-specific agent wouldn't have any physics context for the underlying risks.
reply