tbagman

I know this is also a legal question, but I sometimes wonder about ML-based meeting transcription and summary services. Pre-ML, if you wanted to record a meeting, the de-facto process (at least in the US) was to announce before the meeting that it was going to be recorded, and then announce once you started recording that it was being recorded. Now that we're in an ML world, the default seems to be transcription and summarization is turned on and none of the meeting attendees are asked and most do not have the ability to turn it off.

That feels hinky to me...

Just a note of caution: sync != backup. When I was younger and dumber, I had my own rsync cron script to do a nightly sync of my documents to a remote server. One day I noticed files were gone from my local drive; I think there were block corruptions on the disk itself, and the files were dropped from the filesystem, or something like that. The nightly rsync propagated the deletions to the remote "backup."

D'argh.

Wonderful work and writing, Ronan -- I'm appreciative of your careful balance between objective fact-finding and synthesis.

For me, a big worry about AI is in its potential to further ease distorting or fabricating truth, while simultaneously reducing people's "load-bearing" intellectual skills in assessing what is true or trustworthy or good. You must be in the middle of this storm, given your profession and the investigations like this that you pursue.

Do you see a path through this?

> The most useful, accurate, and honest LLM information I've gathered > comes from spaces where neither extreme prevails

Do you have any pointers to good (public) spaces like this? Your take sounds reasonable, and so I'm curious to see that middle-ground expression and discussion.

Evidence?

It's primarily for hobbyists. From the community discord, I know there are also serious rigs out there as well, on which some members are doing some astronomical science...

I can also recommend starfront observatories (https://starfront.space) for folks looking to do remote hosting. It's in a remote location in Texas with solid skies and great staff, and has a pretty unique model of high density hosting to drive down cost, seeing a ton of deep sky astrophotographers come.

From time to time there are fun collaborative projects too, like https://app.astrobin.com/u/bagman?i=ey9s59#gallery.

The good news is that training jerprint was probably cheaper than training the latest got models...

Homelessness in the US is a complex problem. I found the Soft White Underbelly interview series by Mark Laita insightful when learning more about it: https://www.softwhiteunderbelly.com

Mark spent considerable time earning the trust of LA's skid row population – a large roadside tent community – and has a series of 1:1 interviews with a slice of the population, exploring their histories, challenges, preferences, and culture.

Mark doesn't believe that many (most?) of the skid row population would benefit from being provided with housing, and that issues of trauma, mental health, and childhood family environment are what he believes would have the highest leverage on the problem.

This is of course just one perspective on the problem, but Mark's perspective taught me quite a bit.

Just to say it explicitly, dang, you're doing a great job.

Confirmed; this is what happened to my 16" after this install. I needed to do a DFU restore (using Apple Configurator 2 -- you can download it to your hopefully spare MacBook from the app store) to get my mac back up and running. Unfortunately, for some reason, after the DFU restore, my 16" came back up to do a full reinstall, and I had to restore my files from backup.

Took a day, but all's well now.

Saying a different way: for fork/join or barrier style parallel requests, stragglers set overall latency, and though the probability of any specific response being a straggler may be low, the probability of at least one response being a terrible straggler gets very high at large scales (or large fan-outs).

If you can plug it in, it will work

Unfortunately, this hasn't been my experience. As an example, I have a display-port-based Apple cinema display, and I bought this adapter to try to connect it to a new macbook pro 15":

  http://www.apple.com/shop/product/MMEL2AM/A/thunderbolt-3-usb-c-to-thunderbolt-2-adapter

If I remember correctly (and I might not), the apple store page for this adapter didn't originally carry a warning about this, but instead had text that made it easy to misunderstand whether this would work. The text on the page has changed.

As a weaker example, I have an LG 27UD88 Monitor. The USB-C connection from it works, but only carries 60W of charging "oomph," and the 15" macbook pro needs 85W of charging. So, even though the menubar icon on the mac signals that charging is happening, the battery is actually depleting over time. (Yeah, this one is more caveat emptor than the other, but still.)

Are you sure? I think you're misremembering.

Does rsync.net backup versions of the files you store on it? If not, a pitfall with your workflow is that if you corrupt todo.txt (accidentally, or if there is a filesystem problem, etc.) and then push it via rsync, you'll have accidentally overwritten your "backup" with a corrupt copy.

Agreed on the fantastic-ness -- the first 4-5 in the sequence in particular give you a very nice flavor of working in kernel-space, and they are doable. I taught a senior ugrad OS course and experimented with using this as the project sequence.

Some folks excelled (though they put in 15+ hours per week on average, which is quite high), some cratered and I needed a backup plan for them to make progress.

Paycheck, starring Ben Affleck:

   http://en.wikipedia.org/wiki/Paycheck_(film)

Because of compulsory misses -- i.e., the first request to an object is never in the cache.

I understand your point of view, but I have a different opinion.

When I see these kinds of claims, my guess is that they are usually based on a failure analysis given a particular replication degree and estimates of failure probabilities of various components and failure domains. Underlying this analysis is usually an assumption about the independence of failures between the failure domains.

The good news is that industry has moved away from the computer as the unit of independent failure to a much larger failure domain: often a cluster within a data center, or an entire data center. This means that the analysis takes into account the infrequent occurrence of a large number of correlated failures within the failure domain.

The bad news is that there are inevitably correlated failures across the failure domains, regardless of how carefully you design to avoid them. Software bugs, coordinated attacks, operator errors, cascading failures caused by well-intentioned but runaway control loops and automated failover mechanisms, and so on, can be the culprit.

So, here's the problem. This statistic from Amazon, if taken at face value, would say that relying on Amazon to keep your data durable and safe is practically risk-free to the point of durability issues never happening in your lifetime (or, alternatively, to such a dramatically small fraction of objects that you might not care).

In practice, however, I suspect you do want to plan for the "unknown unknowns" that will cause data loss at low probability, but much higher probability than 0.000000001%.

Here's another way to look at it: I'd love it if Amazon posted some data about the rate at which they've experienced durability failures in the past year or two, rather than posting what I'm supposing (I might be wrong!) are calculations based on assumptions of dependent failure probabilities.

Wow, how the tides have turned! 15 years ago was:

s/Google/Microsoft s/Microsoft/Linux s/Bing/Linux

I never would have predicted somebody cheering for "Microsoft the underdog."

The compromise that intellectual property strives for is to encourage innovation by rewarding inventors with time-limited exclusive rights in exchange for disclosure. The world gains the knowledge through the disclosure, the inventor gains the opportunity to commercialize and earn rewards through the advantage that time-limited exclusion gives them, and once the IP reverts to the public domain, everybody gets the chance to use the invention.

But, factors like patent sharking, the ridiculous extension of copyright terms, the inability of patent offices to properly assess issues like novelty and obviousness, and so on, make it possible for all parties to abuse this compromise.

I think the spirit of the compromise is valid. I think its implementation today has become flawed, but not irreparably so.

It's a complex situation, as other posters have noted.

Here's another complication. Often, faculty need multiple sources of funding over the years to support their research, including federal grants, university support (direct through money or indirect through facilities and staff), and industrial support through gifts and grants. As well, the intellectual heavy-lifting is done by the faculty and their students.

If you believe in intellectual property rights, then who of all of these stakeholders deserves ownership of those rights?

Personally, I lean against faculty patenting their inventions. I'd rather the IP is open to the public. Even if a faculty member wants to commercialize their research, I think they are better off competing in the marketplace rather than through IP arsenals.

But, I understand the other point of view. Patent licensing is a lucrative source of revenue for universities (e.g., UFL and its Gatorade revenue) and inventors. As well, it's at least uncomfortable and perhaps unfair if opportunistic companies were able to commercialize on a faculty member's invention without renumeration or attribution.

Complicated topic.

Good idea; I haven't done any latency studies yet, but that's a great next step...

The really interesting part would be to compute latencies with minification/gzip/both either on-the-fly (e.g., mod_pagespeed) or done in advance, and to figure out what the smallest network latency is for which the on-the-fly minification is still a net win.