For the purposes of an llm "reading" a pdf, it just renders it as an image. The file format does not matter. Let's say you have documents that already exist, a robust ocr solution that can handle tables and diagrams could be very valuable.
Even with regular 5G (sub 6 ghz) you'd take advantage of improvements over LTE like massive MIMO and more precise beamforming. All leading to more people using a network at the same time. Also anecdotally I've found that at music festivals, when cellular data doesn't work, texting or calling usually works fine (At least on AT&T)
Filtering full-color images down to a halftone suitable for book publishing is a mature technology, setting up an ImageMagick pipeline to do so would not be among the hard parts of preparing a book like this. Picking the right still frame out of gifs and video is a bit trickier, but not by much.
Usually you include the database schema in the context, usually by showing the CREATE statement for the tables you want to query. I've also found that including comments in the CREATE sql can guide the model somewhat. The best approach is probably to finetune one of these models using curated questions for your database.
Passthrough also is pretty poor quality, enough to navigate a room but too blurry to read text and the cameras don't handle phone screens that well. Definitely usable but you'll notice you're still wearing a headset.
Cars nowadays have radars and cameras that (for the most part) prevent you from running over pedestrians. Is that also a tool refusing to work? I'd argue a line needs to be drawn somewhere, LLMs do a great job of providing recipes for dinner but maybe shouldn't teach me how to build a bomb.
> LLMs do a great job of providing recipes for dinner but maybe shouldn't teach me how to build a bomb.
Why not? If someone wants to make a bomb, they can already find out from other source materials.
We already have regulations around acquiring dangerous materials. Knowing how to make a bomb is not the same as making one (which is not the same as using one to harm people.)
It's about access and command & control. I could have the same sentiment as you, since in high school, friends & I were in the habit of using our knowledge from chemistry class (and a bit more reading; waay pre-Internet) to make some rather impressive fireworks and rockets. But we never did anything destructive with them.
There are many bits of technology that can destroy large numbers of people with a single action. Usually, those are either tightly controlled and/or require jumping a high bar of technical knowledge, industrial capability, and/or capital to produce. The intersection of people with that requisite knowledge+capability+capital and people sufficiently psycopathic to build & use such destructive things approaches zero.
The same was true of hacking way back when. The result was interesting, sometimes fun, and generally non-destructive hacks. But now, hacking tools have been developed to the level of copy+paste click+shoot. Script kiddies became a thing. And we now must deal with ransomeware gangs of everything from nation-state actors down to rando teenage miscreants, but they all cause massive damage.
Extending copy+paste click+shoot level knowledge to bombs and biological agents is just massively stupid. The last thing we need is having a low intelligence bar required to have people setting off bombs & bioweapons on their stupid whims. So yes, we absolutely should restrict these kinds of recipe-from-scratch responses.
In any case, if you really want to know, I'm sure that, if you already have significant knowledge and smarts, you can craft prompts to get the LLM to reveal the parts you don't know. But this gets back to raising the bar, which is just fine.
Indeed, anything and everything that can conceivably be used for malicious purposes should be severely restricted so as to make those particular usecases near impossible, even if the intended use is thereby severely hindered, because people can't be trusted to behave at all. This is formally proven by the media, who are constantly spotlighting a handful of deranged individuals out of eight billion. Therefore, every one of us deserves to be treated like an absolute psychopath. It'd be best if we just stuck everybody in a padded cell forever, that way no one would ever be harmed and we'd all be happy and safe.
While I agree with this technically and I have used vi(m) for years, there is something experientially quite different about being able to use a local gui with all the mouse support and ease of use of VSCode or Sublime compared to the chording of more traditional terminal editors.
I'm not knocking Emacs or Vim, they are powerful tools but to be able to show a typical first year student how to edit their code remotely using SSH/Container support in VSCode is comparatively dead simple. All the students I work with now use this strategy, much in the same way they prefer to use jupyter and pandas when they can.
Remote editing on Emacs isn't a mere "technical possiblity." It's available out of the box, is no harder than working with local files, and crucially, doesn't require you to install anything on the remote host unlike VSCode.
Furthermore, Emacs still has the best tooling for remote development. They're worth using even if you use other software for text editing, like I do. Dired, the file viewer, makes working with both local and remote files easy and seamless. Org mode, which can be used like Jupyter notebooks, can run code blocks remotely using any language, and can even pass data between them.
It's nice if software professionals were more open towards software that they're unfamiliar with. Software can be useful even if it takes some effort to learn. Not every feature of some software is worthless just because it isn't a clone of a more popular alternative.
I have not found an answer on does it support dealing with containers on remote side, let's assume it does and pass this part.
One day I was not familiar with VSCode and I became familiar and many others as well. Just not Emacs. Assuming you are right and technically Emacs has all bells and whistles, it must be something else that not promoting it for being wide used.
And you skipped the part about VScode tunnels all along.
