lolinder

We're talking about towns of 10k. Traffic in these towns is pretty sparse and easily navigable as a pedestrian.

Heat is mentioned in passing with literally no attempt at quantifying the cost:

> as far as heat goes, well, one could either pay a little extra in electric for that — or they could have the Amish deliver their scrap wood from their sawmills to burn in a wood stove, very cheaply.

That's it. The line in the budget for heat is there and was left intentionally blank:

> Heat:

You can't just hand-wave away the cost of electric heating at the temperatures they get in upstate NY, even if the 0.04 number is accurate year-round (which it almost certainly isn't), and wood-burning stoves use way more wood than the author appears to be imagining with their "scrap wood" comment.

[0] https://www.usclimatedata.com/climate/massena/new-york/unite...

I didn't mean it to be haranguing, but OP was giving what amounted to legal advice that was actually wrong and dangerous. I do think that needs to be called out and clarified—not as a personal attack on OP but just as a matter of safety for readers.

I'll acknowledge that kstrauser may have done a better job of sounding friendly about it, but I don't think my question was out of line nor even particularly aggressive given the circumstances.

[flagged]

This is Microsoft catching up to what JetBrains has had all along (in their paid products). There's DataGrip but I was also using all these features (minus the AI stuff) in IntelliJ Ultimate and PyCharm 5+ years ago.

The main difference is that JetBrains supports a bunch of databases, not just one.

This also means that this line is also inaccurate:

> For convenience, they’re actually hanging from the Jubilee footbridges, one on either side of the railway.

It's not for simple convenience: you can see in the photos that it's because the footbridges are taller then the rail bridge and come a bit before it, which allows them to install the straw hanging at the correct height to warn of the constriction before someone hits the bridge itself.

Here are the top articles for the month of May 2023 on HN with "agent" in the title [0]. Looks like early days for the term but with a few large hits (like the HuggingFace announcement), which suggests OP was surprisingly precise in their citation of two years as the time window.

Also, since you're implicitly questioning OP's claim to have been saying this all along, here's a comment from September 2023 where they first said the same quote and said they'd been building agents for 3 months by that point [1]. That's close enough to 2 years in my book.

[0] https://hn.algolia.com/?dateEnd=1685491200&dateRange=custom&...

[1] https://news.ycombinator.com/item?id=37626877

It also costs 4x the entire Framework Desktop for just the card. If you're doing something professional that's probably worth it, but it's not a clear winner in the enthusiast space.

Nit: TIOBE measures search results, not searches, specifically results for "Kotlin programming". But you're correct that it's a terrible metric for many reasons.

https://www.tiobe.com/tiobe-index/programminglanguages_defin...

Does Nvidia have integrated memory options that allow you to get up to 64GB+ of VRAM without stringing together a bunch of 4090s?

For local LLMs Apple Silicon has really shown the value of shared memory, even if that comes at the cost of raw GPU power. Even if it's half the speed of an array of GPUs, being able to load the mid-sized models at all is a huge plus.

You're not getting it: this is already happening everywhere. There is no private data on public Discord servers. Never has been.

All these researchers have done is admit to doing what many less well-meaning people and organizations are already doing on a regular basis. If that admission leads to more people realizing that public Discord servers are public, then the researchers have done everyone a service.

Blaming the researchers in this case is like blaming LockPickingLawyer for locks being pickable. The bad guys were already picking the locks before he started his channel, all he did was shine a light on just how bad most locks are.

Note that they started saying that recently after their earlier projections didn't pan out. The "uneven process without a clear finish line" angle was Altman recently trying to reset expectations, which means it doesn't contradict OP's thesis that this move towards product is further admission that AGI is going to be much messier than they initially predicted.

AGI is the ultimate money factory if they could deliver it on the timelines that they were projecting until recently.

The reason why Apple has failed to integrate AI successfully into the iPhone isn't because we need an AI-first device, it's because AI is still universally being strategized as a solution in search of a problem. An AI-first device at this stage will fail for the same reason: it doesn't have a mission statement to solve particular problems for real people, it has a mission statement to be an AI device.

The absolute best case scenario for an AI-first device at this stage is that it ends up like the Vision Pro, which had a similar mission problem.

This is a bet that's as insane as the Apple car. They're going to try to get people to buy a specialized device from a company that isn't just a software company but really a B2B API company—the only successful consumer-facing product they have ever released was an accident, a tech demo that went viral.

And what exactly is that device going to do that the iPhone (and smartphones in general) can't already do with at a minimum a few small tweaks to the existing flagships?

In the right context vertical integration can make sense, but hardware is a big stretch for OpenAI right now. They haven't even really pinned down the consumer software angle yet.

Eh, even that is too strong. Discord already recorded the conversations and makes them publicly available to anyone who joins the server at any point in the future. Anyone who thought they were having an ephemeral conversation that wouldn't ever be seen again by anyone has never tried scrolling back on a Discord server.

Creating the database got attention in a way that just pointing it out wouldn't have. You point it out and people shrug and say "sure, that's totally unsurprising". You produce more than 100 GB of data and you have people's attention.

These databases exist and always have because this has always been possible. The only difference is that they've typically been held close to the chest by intelligence agencies or hacker groups or whoever else made them for illicit purposes. The only change here is that this database is public and is drawing mainstream attention, which is a strictly good thing.

A lot of the people on here are using the same reasoning that would say that LockPickingLawyer should stop showing how to pick locks because he's making it too easy to learn how garbage most locks are.

> it is actually the spiritual successor to IRC, AIM, and similar chat services, where the data is typically ephemeral

I can't speak for AIM, but I've never assumed IRC was ephemeral. Most IRC servers had and have numerous people idling in the channel with their client just archiving everything that happened. Many of those archives ended up published on the internet and that usually surprised no one.

Discord is even worse because it does the archiving for you and grants new users immediate access to the entire archive.

As a rule, each and every recipient of every message that you send has the option to archive or forward that message. That's a simple fact of information flow that everyone in the modern world must wrap their heads around. In this case, when you send a message to Discord you're transitively sending it to everyone who is currently or ever will be on a given server. That has always been true, and that fact has been exploited ever since Discord came about.

All these researchers have done is expose the kind of archiving was always possible and always happening.

They're not going through all of my messages. I don't use public Discord channels for anything that I wouldn't want the public to see.

Mostly I think it's weird how many people on here seem to have been under the illusion that Discord is somehow ephemeral and private when I can hop on any public server and scroll back indefinitely to see anything that anyone has ever said on that server. And that's before I get into the API and the (admittedly bad) search feature.

I think what you were looking for is Signal or similar.

On the contrary, I think that what these researchers did was the only ethical thing to do once they discovered that this was possible.

There's no way that this hasn't been done dozens of times before by intelligence agencies, hacker groups, and whoever else you care to worry about. Most of us here were well aware that public Discord channels have always been public and durable. It's hardly a secret from the technically savvy, it's just that Discord doesn't make it clear enough to regular users.

All this paper changes is that it draws mainstream attention to what was already happening illicitly for as long as Discord has been around. This can only be a good thing: the children and teenagers 404 is so worried about have always been vulnerable to their data getting leaked just like this, it's just that up until now that's been happening in the dark so as not to kill the golden goose.

These researchers are just using the tools that Discord made available to archive information that was already public. If anyone is to blame for users believing that their messages were private or ephemeral it's Discord, not the researchers.

Look at it like this: There's no chance in hell that intelligence agencies, hacker groups, and whatever other nasties you care to worry about haven't already been using archives just like this for all their nefarious purposes. They just didn't make their usage public because why break the honey pot?

What these researchers did is show what was possible and make their efforts public. Now you are better informed of what was always possible. It's always been necessary to think carefully before putting stuff on the internet, it's just now your bubble is burst.

These researchers are making public scraping that was already happening in private. Do you really think they were the first ones to realize that public Discord servers were public?

On the contrary, kudos to these researchers for bursting the illusion that people previously had that things said on public servers somehow would be ephemeral. That's not how the internet works, that's not how it's ever worked. If you send something to someone else's computer you have always had to assume that every recipient could have made a copy of it, and when the recipient list is "everyone who ever joins a public Discord server from now until the end of time" that makes it public information.

Better that it be widely recognized and talked about as these researchers are doing than have accessing public data remain a dark art that lay people mistakenly believe can't happen.

The pace of things does not ensure that whatever you say remains buried. Discord has a search feature that isn't great but does work. If you want to ensure that what you say is ephemeral you need to use a chat app that has that as a feature, like Signal.

That sounds like an enormous flaw in Discord's permission model, not something that should be patched over with "shame" on researchers for archiving data that Discord made public.

The fact remains that if you post something in a private discord channel that someone takes public, it's now public information. All these researchers did is expose that fact—the fact that private messages can later be made public is Discord's responsibility and Discord's shame.

Fair enough, I guess I haven't looked in the last few years. The last time that I did a search for .NET there were about five different names that were available and Mono still turned up as the runtime of choice for cross platform (even though I knew it wasn't any more).

I read the article when it hit HN months ago but I don't agree that function coloring doesn't apply. What you're describing is that Rust makes coloring less painful, not that functions aren't colored.

JavaScript itself has come a long way towards making coloring less painful. TypeScript+ESLint solves the weird unpredictable behavior issues with JS and async/await solves the syntax issue. Promises in general give well-defined semantics to calling an async function from a sync function. But all that only undoes some of the arguments about function coloring, not all of them. Fundamentally the same question applies: do you make async-ness part of the type system or do you instead build a system like green threads that doesn't put it in the type system?

I happen to think that coloring functions according to their async-ness is actually the right move (with the right ergonomic improvements), but plenty of people don't agree with me there even with all the ergonomic improvements Rust and TypeScript have made to the model.

I'm not talking about JS. I had Rust in mind.

Also, promises already color functions just like callbacks do. Async/await just changes the syntax by which that coloring is expressed. The real problem people have with async is that they prefer green threads as a solution to concurrency, not that they don't like the syntax.

It was always going to be too risky for a subset of users, from the moment they announced it. That would not have stopped a project that was not VC funded—a smaller project with less at stake could easily have stuck to their guns and just appealed to the people who were actually interested in pioneering a new ecosystem.

To be clear, I like async. I just don't think "you don't have to use it if you don't like it" is a good argument in favor of it because it's obviously not true.

> If a Deno library uses a Node API or an npm library somewhere, it can be entirely encapsulated, so you might not even notice until you see it in a stack trace. That doesn’t seem very intrusive?

Node API yes, NPM library no. If you add a dependency on a library that uses NPM you now depend on an entire web of transitive NPM dependencies, with all of the problems that entails. People don't dislike NPM because it's aesthetically displeasing—you can't just abstract away the problems with NPM. The ecosystem causes real problems with real software, and Deno initially recognized those real problems and set out to reset the ecosystem.

The only way in which NPM-compat is different than colored functions is that there's no static compiler feature telling you when you've added a dependency on a bunch of NPM libraries.