ipsi
This is not to say you can't or shouldn't use AI, but it's important to understand the tradeoffs you're making.
[1] https://www.scotusblog.com/cases/thaler-v-perlmutter/ [2] https://www.jenner.com/en/news-insights/client-alerts/us-cop...
Which could be summarised by a single line: "In other words, the primary cost of change increasingly becomes feedback delay, not development effort."
[1]: https://code.claude.com/docs/en/channels [2]: https://code.claude.com/docs/en/channels-reference
I do notice that the more Claude-generated stuff I read, the more it creeps into my daily usage, and I suspect I don't read nearly as much of it as an Anthropic Employee would, so I could believe that. Though "much of" isn't the same as "written with zero AI generation/rephrasing/etc."
Anyway, that aside, something I would like to see is an example of something that's possible with this system that isn't, or isn't easily, possible with existing Claude hooks. Right now it reads like "Here's a cool thing! Here's how it works! And here's this other similar system we have! Here's how that works!" But there's no summary of the differences, why I'd use this over regular hooks, and so on. Or at least not that I saw on quick skim, and I'd be looking for that to be mentioned as early as possible, so I know if the rest is worth reading.
For companies? I think that's a lot more plausible, as that's mostly just a question of money - is it cheaper to run and administrate our own models, or outsource that?
For technically inclined users? I think that's unlikely unless they're able to operate on relatively cheap hardware while still being just as good as the hosted models. And by that I don't mean "a mac studio," that's far more money than I think is reasonable. A single RTX 5080, maybe, once memory prices start to drop.
For port binding, for example, it used to be that you'd deploy your app to the web application container, rather than bundling them together. e.g., deploying your WAR file to Tomcat, rather than building a self-executing JAR which included Tomcat. The wording is a bit odd, but I think they were trying to make the point very generic, and not specifically about the Enterprise Java world.
For the backing resources, it's a combination of point 3, config often living inside the codebase, applications just shelling out to /usr/sbin/sendmail or what have you, and applications living on the same host as the DB, such that bringing up a new application necessarily required bringing up a new DB as well. Which also made it hard it to scale horizontally.
The whole "12 Factor" thing was partly because Heroku had specific solutions for all of these, so going down this road made it much easier to then sell Heroku, and partly because they really were frustrating. I'd say that the port binding one is more targeted at, say, WebSphere, and all that came along with it, such as sharing a single heap across multiple apps, needing to talk to the WebSphere admins to change configuration, needing to use a "lite" version of WebSphere to test locally, if that was even possible, and so on.
They sound super-obvious these days, but at the time, for a lot of us, they were really nice to see.
I don't play a lot of competitive Overwatch, but it's definitely a much nicer experience with chat turned off, even if I'm not the one being flamed, even if we lose because people are typing instead of shooting.
1. It tells you which variable is null. While I think modern Java will include that detail in the exception, that's fairly new. So if you had `a.foo(b.getBar(), c.getBaz())`, was a, b, or c null? Who knows!
2. Putting it in the constructor meant you'd get a stack trace telling you where the null value came from, while waiting until it was used made it a lot harder to track down the source.
Not applicable to all situations, but it could be genuinely helpful, and has been to me.
EDIT: It's worth noting that this is mostly a spoken thing, AIUI - most formal/semi-formal writing would be in Hochdetusch rather than a local dialect.
Turns out that under certain conditions, such as severe exhaustion, that "sus filter" just... doesn't turn on quickly enough. The aim of passkeys is to ensure that it _cannot_ happen, no matter how exhausted/stressed/etc someone is. I'm not familiar enough with passkeys to pass judgement on them, but I do think there's a real problem they're trying to solve.
If I could rely on every Rasthof having multiple functional EV chargers, I think range anxiety would be far, far less of an issue for me, but as of now it's something that I do think about for longer trips, and do have to plan for.
* In the big cities, increased rents will almost immediately eat up the extra income from the UBI, and there won't be any meaningful change in the status quo for anyone who rents — which I imagine includes the majority of the people who do the important but undesirable jobs.
* Anywhere that the people doing these jobs either can afford houses (smaller American towns, e.g.), or where there's enough rental supply that rent won't immediately go up by the same amount as the UBI, will have to start paying people more to do these jobs. As far as I understand it, jobs like trash collection are already relatively well-paid given the training and qualifications required, so they might not even have to pay that much more.
If you're playing sessions with a lot of RP, DW will have a much better balance of rules:session-time, it's much easier to prep for, and given how rules-lite D&D really is outside combat, will probably have about the same amount of narrative input. Note that it's not necessarily the "group debating if the player survived", but typically the GM giving the player a choice when they fail to climb the wall, like "you fall and take a little damage, or you slip a little, cursing loudly and alerting the enemies at the top to you".
Done well, it gives the players a lot more agency, and much better buy-in for the story as they're now shaping it, instead of just being along for the ride. I would also say that pre-written narratives aren't really a thing for DW (at least, as far as I know!), so it's really down to what the DM sees as an appropriate penalty or choice, often phrased as "you succeed, but <thing>".
It's not really better or worse than D&D overall, I'd just say that it's much better suited for certain play-styles. If you enjoy tactical gameplay and using miniatures, then D&D (or maybe Pathfinder) are much better options. If the thought of yet another fight makes you want to gouge your eyes out, I'd recommend giving DW a try.
An example of how I might provide references with page numbers or chapter names would be great (even if this means a more complex text-extraction pipeline). As would examples showing anything I can do to indicate differences that are obvious to me but that an LLM would be unlikely to pick up, such as the previously mentioned in-character vs out-of-character distinction. This is mostly relevant for asking questions about the setting, where in-character information might be suspect ("unreliable narrator"), while out-of-character information is generally fully accurate.
Tangentially, is this something that I could reasonably experiment with without a GPU? While I do have a 4090, it's in my Windows gaming machine, which isn't really set up for AI/LLM/etc development.
Basically, I'd like to be able to take PDFs of, say, D&D books, extract that data (this step is, at least, something I can already do), and load it into an LLM to be able to ask questions like:
* What does the feat "Sentinel" do?
* Who is Elminster?
* Which God(s) do Elves worship in Faerûn?
* Where I can I find the spell "Crusader's Mantle"?
And so on. Given this data is all under copyright, I'd probably have to stick to using a local LLM to avoid problems. And, while I wouldn't expect it to have good answers to all (or possibly any!) of those questions, I'd nevertheless love to be able to give it a try.
I'm just not sure where to start - I think I'd want to fine-tune an existing model since this is all natural language content, but I get a bit lost after that. Do I need to pre-process the content to add extra information that I can't fetch relatively automatically. e.g., page numbers are simple to add in, but would I need to mark out things like chapter/section headings, or in-character vs out-of-character text? Do I need to add all the content in as a series of questions and answers, like "What information is on page 52 of the Player's Handbook? => <text of page>"?
So to that extent, I think there's quite a lot in common between engineering and management tracks after a certain point, both because there's a genuine need for that, and because direct code contributions just don't scale in the same way that helping others does.
I definitely wouldn't expect it to be high on the list of priorities, but I do appreciate that it's under consideration at the very least.
Another example is "krächzender", which might also serve to give some idea of the particular pains in processing German text. It's not in English Wiktionary, but krächzen is, and is a verb. So "krächzender" is the adjectival form of the verb, and if you know "krächzen" and the general rules around adjective formation it would probably be obvious. But would you rely on a computer to parse those rules, or would you want a table with all the declensions laid out? And if you're building a vocab list for a book, is it a separate entry in the list, or does it fall under the verb?
Obviously, German Wiktionary only has definitions & explanations in German so it's not great for beginners, but any tool that's trying to automatically do stuff with German text would likely benefit from using German Wiktionary.
I have no idea if it's true for other languages, but I wouldn't be surprised if it's also true for other major languages spoken by Wikipedia users (e.g., French, Spanish, but maybe not Chinese).
There's a nice project for converting and extracting the data from English Wiktionary into JSON but it doesn't support any other languages, AFAIK, which is a bit of a shame but also not very surprising - Wiktionary is a lot more complex, technically, than I expected!
Reasons it's useful: * If you've got both Native & Target Language subtitles, you can see a natural translation if you're struggling to understand something * If there isn't a Native translation, then you can machine-translate one - especially useful early on to catch common idioms/etc that aren't just the sum of each individual word. * Jellyfin also supports eBooks, although its reader isn't great - but if someone has already built their library, it would be nice to be able to re-use it somehow.
I would be very interested in seeing that particular feature expand, but I don't imagine it's at all simple!
Tangentially related, but I could see some desire for Calibre support as well, somehow. Calibre was very much designed to be completely stand-alone and it doesn't really support other apps trying to read its database, but it is possible.
I'd also really like some language-specific features, like separable-verb handling for German (see this comment: https://news.ycombinator.com/item?id=38915786) - it's relatively important and lacking support really limits the usefulness of vocab tools. It would also be a nightmare to handle for subtitles, since it's not always clear where a sentence ends, but such is life - subtitles are sadly not aimed at language leaners. For books and not-terrible Podcast transcripts, though, it wouldn't be so bad.