It's so great. I've been this vision model to rename all the files in my Pictures folder. For example, the one-liner:
llamafile --temp 0 \
--image ~/Pictures/lemurs.jpg \
-m llava-v1.5-7b-Q4_K.gguf \
--mmproj llava-v1.5-7b-mmproj-Q4_0.gguf \
--grammar 'root ::= [a-z]+ (" " [a-z]+)+' \
-p $'### User: What do you see?\n### Assistant: ' \
--silent-prompt 2>/dev/null |
sed -e's/ /_/' -e's/$/.jpg/'
Prints to standard output:
a_baby_monkey_on_the_back_of_a_mother.jpg
This is something that's coming up in the next llamafile release. You have to build from source to have the ability to use grammar and --silent-prompt on a vision model right now.
I don't quite get the study plan, as it sounds more like cramming. Nothing wrong with cramming per se except that what you learn does not stick, and you will have to repeat the process when you need to switch jobs again.
I think a better system is to regularly study fundamentals and always deep dive in your work. Case in point, I've never had problems passing interviews by FAANG or other hot startups, I always got title bump when switching jobs, and I never spent extra time prepping for interviews. Say you're an ML engineer who builds an image recognition pipeline using Spark and PyTorch. Do not just be content with assembling a number of open-source solutions to make your pipeline work. Instead, study the internals of Spark, understand the math and algorithms behind your image recognition models, read survey papers to understand the landscape of data processing and image recognition or further, machine learning, and implement a few models and try to optimize them. Similarly, if you work on database systems, do not just stop at being familiar with MySQL or Postgres or whatever. Instead, understand how transactions work, what consistency means, how principles of distributed systems play out. Study Jim Gray, Gottfried Vossen, Maurice Herlihy, Leslie Lamport, the database red book and its references... You get the idea.
As for leetcoding, replace it with study of algorithm designs. Study Jon Kleinberg's book or Knuth's writings (no, you don't have to read through his books, but his writings are incredibly insightful even for mortals like us), for instance. Instead of working out hundreds of back-tracing problems, study backtracking's general forms.
People tend to underestimate the effect of regular study for years. You'll find that in a few years your knowledge will converge and you will be able to spend less time to incrementally improve your skills, and you will have so many concepts to connect to greatly benefit your projects.
Bought a digital piano and started learning piano from scratch. Been trying out different software for learning piano using MIDI input. (Simply Piano, Playground Sessions, Flowkey, Piano Marvel).
Sorted and deduplicated all my photos.
Set up backups for all my important stuff using Restic to BackBlaze B2.
I was doing weekly groceries since last summer and had partially automated the process of aggregating the ingredients into one grocery list already.
When the social distancing started I figured maybe others would find this tool useful, so I spent a couple of days building a usable interface and account creation features and told some friends on Facebook. Nobody, besides me and my girlfriend, ended up really using it, but it was a nice exercise nonetheless ;).
Yes, I for every API I build I setup a few specific heartbeat style endpoints. I have done this since I was a consultant and even now I do it within the company I am at now.
1. Heartbeat, which checks the service is responding. Used for HTTP monitoring services to make sure the route is up mainly.
2. Heartbeat which checks the service is up and validates all database connections are up and I can get data from the database (usually a trivial query on a small table). Used as the primary detection for internal failures.
3. For any 3rd party services I depend on I setup a heartbeat endpoint for them that will check the service is up (but not necessarily giving me good data). Usually I group them, sometimes I group and separate them under like /heartbeat/services, /heartbeat/service1, /heartbeat/service2. Sometimes you can validate the service is returning good data but not all the time is it easy to do that, so I do what I can.
4. I setup a 3rd party service to monitor the heartbeats and the return code to validate they are up and properly returning what I expect, notify me if not. I don't have to do sophisticated response processing at the 3rd party service because I can just use http return codes 99% of the time. The detailed response checking is done at the heartbeat level, then a response code generated. And of course, any failure to respond shows too.
This is still not perfect, but it has proven to make sure we know before anyone else when something fails. I still have one product that we haven't converted to this process right now but we are migrating to a new version that has these checks so it will help me sleep better the faster that happens.
One key thing is don't make the check interval too crazy, the general http is used a lot for the load balancers, but the others are spread out a lot more to reduce creating artificial load. When we build an independent service (microservice etc) I make sure they have these same checks, although it might not be http based. But since they have the same basic methodology a service watcher can remove any instance from the registry if a check fails after some configured number of failures & retries etc.
Python can do something similar albeit far simpler via packaging as an executable zipfile. Just structure everything you need in a directory and zip up with __main__.py in the root. All resources are available as an in-memory binary stream, including individual source .py files. Of course if you want to package something like a C library, you need to unpack that to disk to be able to access it with ctypes.
Heh, I made a similar thing (mostly unreleased/undocumented at [0], original idea at [1]) that would take your Go code, build a binary wrapper for it using the target OS arch, SSH to the target, SCP the file over, run the binary, connect stdout/stderr/stdin with the remote, allow the remotely running binary to request files from the home binary, and delete itself once complete. One thing I found is SCP/SFTP is a really slow transfer protocol and an alternative should be made available as an option (but leave SSH as the default).
I believe that we are getting to a point where config management might as well be in a programming language instead of a bunch of ad-hoc scripts in templates that defer to dynamic language scripts and become a mess.
Some magnificent genius has created the perfect bot for hooking predatory telemarketers. "Lenny" is a slightly confused elderly man with poor hearing. He wanders off topic, he isn't sure what you just said and he is absolute catnip for crooks. If you haven't heard a call to Lenny, you're in for an absolute treat. This call from a tech support scammer lasts an exhausting 31 minutes:
I'll be trying this out, it could work well with Cloud Torrent. I've largely moved away from Torrents tho and switched to using NZB's and apps that automatically download tv shows and films[0]
Hardware is a pair of HP Proliant Gen8 microservers, Ubuntu 14, Docker, nginx and LetsEncrypt. There is no real easy way to set this all up, you have to do each part of the stack yourself (a docker-compose file would go a long way to simplifying it)
[0] I spend over $200 a month on content subscriptions so I don't feel bad about utilizing the conveniance of NZB downloads + Plex
This already exists. It's called noti. It's cross-platform, supports most of the same backends, and can send Slack notifications (which ntfy can't). It also has an awesome API. You can put `noti` at the start of a command or `;noti` at the end, which is what I always do. I never remember to set the notification until after I've typed the command. If you forget to set the notification and the command is already running, you can call `noti -pwatch <pid>` and set notifications after the fact. It's very well thought out.
Weights here: https://huggingface.co/jartine/llava-v1.5-7B-GGUF/tree/main
Sauce here: https://github.com/mozilla-Ocho/llamafile