Meta, but I love the simplistic design of the landing page. That textured background is so much less brutal than a solid colour. I thought about using a background like that in my terminal (to give it a very subtle paper like quality) but was surprised to find nothing online about other people doing the same (I had hoped for screenshots and texture packs).
Eterm used to have a support pack with some nice backgrounds for tiling, which sadly appears to be more difficult to find than it would've been a decade ago. I did find a mirror¹, but that is purely because I remembered the filename for some strange reason. Some of the textures in tile/ are still quite nice, but not all of them work so well with our modern higher resolution displays from a quick play.
Its curious you couldn't find anything, tons of terminal emulators out there support this, I'm not sure what platform you're on, but on macOS, iTerm2 supports image backgrounds, on Linux, kitty is my goto customizeable terminal emulator, and I think even the new Windows Terminal supports them! Also, I think gnome's terminal emulator has an effect like this on it by default (or at least it did in some distro's default setup I've used)
It wasn’t that I couldn’t find a terminal supporting background images (indeed, this is very well supported). It was that I couldn’t find anyone referencing using subtly textured (slightly noisy) images to avoid a very solid background.
Most of the ones I’ve seen that support backgrounds have the usual options to tile/stretch the background, what’s stopping you from finding a pattern you like and making it a tiling background? There used to be a (now defunct) site out there called subtle patterns that had a massive CC0 library of these kinds of textures, toss it in an image editor, apply a color you like, tile it and call it done!
Agreed. And chatbots also leave no room for discretionary exemptions. My headset microphone broke recently (after the warranty period) - emailing the company and asking if there was any way I could buy a new one netted me a free replacement and a nice note from a real person. I’m 100% convinced that a chatbot would have told me that based on the serial number my headset was out of warranty and ended the chat.
This is a shallow reading of what a “bot” could be capable of. Whoever is running customer service at that company has obviously decided that for certain situations people should be entitled to courtesy replacements. That decision was not contingent on who is taking the calls. When that person makes the decision to shift some/all workload to chatbots, he, or she could easily teach the bots what types of courtesy repairs or replacements should be considered, and the criteria they should meet.
For instance, in your case, the rep probably knew that the part cost a couple bucks and the postage cost a buck or two, so a three dollar expense was deemed well worth it for goodwill.
This is the kind of thing that a bot would be just as good at, and it’s also a thing that does not automatically happen just because the agents are humans. Some companies would fire the human rep for giving you that freebie.
Honestly, the real reason why bots will be a good thing is that 3/4 of customer service calls come from confused people who really just need handholding. Setting the jobs issue aside, which is going to be a much bigger question across humanity, eventually I’d like to see bots handle that 3/4 of calls. Half the customer service staff could be retained and deployed exclusively to handle the issues actually worth their time.
It would be great if everyone made personal financial sacrifices for the things we thought were important right? The world would be a much better place in my estimation.
Relying on individual developer's ethics is not going to work. "There's always someone willing to write the kill-bot software." I've in the past objected to (and refused to) develop ethically questionable software. It doesn't make a difference, because Bill, two desks down, is happy to write whatever software boss tells him to write.
no the govt should just pay ubi because we're at the point of needing it. it'll only get worse. Businesses should automate so people are needed for less menial stuff and can just enjoy life and shit.
Not far from now even intellectual jobs will be a.i.
post scarcity star Trek civilization is very possible if we stop letting greed control us.
disclaimer : I run an ai automation agency, and support the fight against poverty and for universal healthcare and stuff, but the faster we automate the faster the govt is forced to roll out solutions to fix the problems automation creates.
Except, LLMs don’t cite their sources accurately (if at all). A Google search may yield information with a source I can verify; my understanding is that LLMs are fundamentally incapable of doing so.
An LLM backed by an embedding store absolutely backs its sources. It’s a solved problem. But people cling to the narrative because that takes the fear away.
If one gave you a 10,000 page bibliography would you read all the sources? The same problem exists (long bibliographies) in human knowledge transfer. I’m suggesting this is an architectural issue, not a LLM problem per se. LLMs are not supposed to be AGI.
An actual citation and a string that happens to be formatted to look like a citation are very different. I wish we were at the point that most LLMs could do the former.
I've seen the former happen for some GitHub docs and when enabling plugins.
I agree there's cause for concern, and I hope it's a gradual rollout that's introspected in between each propagation of such, but I definitely think it's viable to be used no more less safely than other tooling in the government today (for better or worse).
Python runtime deployment is a major pain point for us (CS department at a university).
On the most tightly managed lab machines, which are all in lockstep on a fixed configuration (latest Ubuntu LTS with a updated image pushed annually), we can provide a consistent Python setup (e.g. Python 3.10 and a fixed set of C-based modules like psycopg2). However, our staff and PhD desktops and laptops are more diverse - with the OS often only being upgraded when the distro is going out of support, they could be running n, n-1 or n-2. That, most likely, means three different Python versions.
We could use pyenv to let people install their own preferred version. Installing with pyenv requires building from source (slow on some of our oldest machines). This also means installing the Python build deps, which is fine for our departmental machines but not possible on the HPC cluster (operated by a different business unit) or the Physics shared servers. It's also less than ideal for our servers where students deploy their projects (where we want to minimise the packages installed, like the build-essentials meta package).
It's also a massive stumbling block for less experienced students with their own laptops which could be running any distro, of any age. Many CS101 or engineering/business/humanities students taking a programming class, who have never programmed before, would really struggle.
So, classes might tend towards teaching lowest common denominator Python (i.e. the oldest conceivable version a student might have installed on their machine).
Sure, we have in-person and remote lab machines students can use - but it's not always convenient (especially for the data science / ML students running Jupyter notebooks with their own GPU).
There are workarounds, but they all have serious downsides.
Compared with Node.js and Go, where users can just download the appropriate package and unzip/untar the runtime or compiler version of their choice, deploying the Python runtime has enormous friction (especially for less experienced users). This has the bonus of simplifying deployments elsewhere in our infrastructure (CI/CD, containers, etc).
And while we all complain about node_modules, Python venvs not being trivially relocatable is another huge frustration.
We've used Anaconda, but that comes with its own issues (most recently, finding that it ships with its own gio/gvfs binaries and libraries which fail to mount our CIFS DFS shares - causing confusion for users running `gio mount` from within a conda environment).
