The best way I have found is to setup keepalived -> pgbouncer -> Postgres. Use repmgr to manage replication and barman for backups. Setup a VIP with keepalived with a small script that checks if the server is primary. You loose about 7-9 pings during a failover, have keepalived check about every 2 seconds and flip after 3 consecutive failures.
Thank you! A blame focused culture rewards the least amount of risk taking, the most ass covering, and so much useless bureaucracy because you naturally accumulate systems to convert individual blame to collective blame like change review boards and multiple sign-offs for everything. Folks do the bare minimum because that's the safe subset.
I'm never going back to that kind of culture, it's soul crushing.
This episode of Kris Jenkins' Developer Voices podcast talks with a couple authors of a new book on DuckDB, and does a great job of explaining the sorts of things that make it so unusual: https://www.youtube.com/watch?v=_nA3uDx1rlg
I really need to dig into the more recent advances in knowledge graphs + LLMs. I've been out of the game for ~10 months now, and am just starting to dig back into things and get my training pipeline working (darn bitrot...)
I also trained it on generating KGs from conversations, or articles you have provided. So from the LLM side, it's way more knowledgeable about the connections in the graph than GPT4 is by default.
Here are a couple examples of the trained model actually generating a knowledge graph:
I haven't done any work on integrating those into larger structures, combining the graphs generated from different documents, or using a graph database to augment my use case...all things I am eager to try out, and I am glad there is a bunch more to read on the topic available now.
Anyways, near term plans are to train a llama3 8b, and likely a phi-3 13b version of Inkbot on an improved version of my dataset. Glad to see others as excited as was on this topic!
While there are no silver bullet, for beginners, I found that "Relieving your Python packaging pain" (https://www.bitecode.dev/p/relieving-your-python-packaging-p...) is the Pareto solution. That is, the solution that has the best ratio of effort, reward, but also the lower risk of failure. It's not no risk, but I've been helping beginners for 15 years with Python, and have tried everything you can think of.
It does imply, on linux, to limit yourself to the choices of Python you can install. This constraint is, for most people, preferable than the alternative, even if it gets frustrating to our geeky soul.
Every comment in that thread, including the comment you referenced, is wrong.
Due to Poetry's architecture, it can't satisfy all three at the same time:
- the platonic ideal of build isolation and lockfiles
- installing the appropriate accelerator specific version of pytorch for the current platform non-interactively or one that the user selects
- dependencies for pytorch that are transitively compatible with the way dependencies for pytorch are expressed elsewhere
This is something you can achieve with setuptools and setup.py by forfeiting the platonic ideals of build isolation and lockfiles.
Poetry, on the other hand, does not let you choose which lamb to sacrifice. Everyone in the thread, for the last two years, who has reported that they have had some success are misunderstanding the state of their install, and have interacted with flaws in all three situations I'm describing. They have something that will not correctly install anything that is dependent itself on PyTorch, which is useless, since everything in the PyTorch ecosystem is is dependent on it, and the main workaround the community uses - installing torch first, followed by installing dependencies from a requirements.txt, followed by copying a dump of scripts - is not compatible with poetry.
2/3rds of Python end users do not engage with packaging at all. pyproject.toml with dependencies is about 1.5% of the ecosystem. It provides only downsides compared to setup.py and pinning your package versions by commit in your setup.py dependencies aka doing what golang does, and this does not require any external tools in Python. In my opinion, the Poetry developers need to fix pytorch or they will not get adoption during Peak Python.
A quick check puts a Ryzen 5 5600 and a Radeon RX 6600 at $360 combined, where the 8700G is set to $330. And a RX 6600 will deliver around double the graphics performance. So even without factoring in motherboard and memory the 8700G is hard to justify for a cheap gaming rig.
Ha! I took a phone call back when I was in the shiny round disc business that said based on the prices we were quoting, that we'd be out of business in a year because Apple released DVD Studio Pro. Instead, we gained even more business from people that tried to have their projects done in DVDSP, but then ran into road blocks making it impossible to do the job. They'd then come back to us, and receive an even higher quote since now there is even less time before their deadlines. cie la vie.
You say out of business. I say, mediocrity all the way down from here.
Yes! The obvious answer is to just increase your positions and train for that. This requires a ton of memory however (context length is squared) so most are currently training at 4k/8k and then finetuning higher similar to many of the image models.
However there's been some work that to "get extra milage" out of the current models so-to speak with rotary positions and a few other tricks. These in combination with finetuning is the current method many are using at the moment IIRC.
The bottleneck is quickly going to be inference. Since the current transformer models need the context length ^2, the memory requirements go up very quickly. IIRC a 4090 can _barely_ fit a 4bit 30B model in memory with 4096k context length.
From my understanding some form of RNNs are likely to be the next step for longer context. See RWKV as an example of a decent RNN https://arxiv.org/abs/2305.13048
Yeah that's a fairly well studied one. Most of these techniques are rather "lossy" compared to extending the context window. The most likely "real solution" is going to be using various tricks and finetuning on higher context lengths to just extend the context window.
Not for pure python code; but there's massive advantages for mixed C(++) and Python: I can now have multiple sub interpreters running concurrently and accessing the same shared state in a thread-safe C++ library.
Previously this required rewriting the whole C++ library to support either pickling (multiplying the total memory consumption by the number of cores), or support allocating everything in shared memory (which means normal C++ types like `std::string` are unusable, need to switch e.g. to boost::interprocess).
Now is sufficient to pickle a pointer to a C++ object as an integer, and it'll still be a valid pointer in the other subinterpreter.
The harm of kitchen knives, fire, electricity, thinking, and getting out of bed all clearly exceed 0. This suggests to me that it's fundamentally wrongheaded to think of it as the primary metric by which we evaluate things.
Certainly! In this case, they were interested in files that were too permissive.
I don't have a good example of the command, but it was basically looking for 'worldly' permissions that were too open. It's important to note the users/groups could be discarded/ignored.
They were using 'find ... -exec ls -ld {} \;', which does an LDAP lookup on each result to resolve UIDs and GIDs to names.
They could have made the process far more efficient with either the native '-ls' argument built into find, or adding '-n' to the exec'd 'ls'
Either would skip the name resolution/domain. At a certain number of results/files the expense is too high, causing the job to time out
- 20x20x4 MERV12 filter. The 4-inch pleating is key here, to reduce the air resistance on the box fan.
- 1 inch dust pre-filter. This is course, low air resistance, and is for increasing the life of the more expensive MERV12/HEPA filter (so it doesn't get clogged with easy to filter dust).
- Both filters are on the intake side of the box fan. This means you don't need a bungee cord because the intake has negative pressure, the filters just "stick". It also means you keep your box fan flowing with only cleaned air.
As I get older, the less I identify as my current state and the more I identify with the person who transitions through states. My change in perspective has reduced my anxieties and anger significantly. "This too shall pass" and all that. The more of my self image is focused on superficial things, the more I will take things personally. What we are angry about tends to be a reflection of ourselves more than the current state of affairs.
If I see myself as a busy professional I might be much more aggravated by someone at the grocery store holding up the checkout line with EBT (since I am busy they must be lazy!). If I see myself as a social climber I will always be worrying if people are using me for something (since I am using them!). If I identify with my wealth I might develop some neurosis regarding the sight of the homeless (since they represent ultimate failure!).
I don't believe in reincarnation but it is a helpful thought experiment to think about what benefits and drawbacks your particular incarnation of life holds and how those might be different if you were incarnated elsewhere.
> Why can’t I just click a button and follow all the local events for my favorite artist/venue/team/theater/charity? Why do I still have to manually create events and copy and paste details? Why are there so few “add to calendar” and why do they often fail?
It's because of advertising.
Artists, venues, teams, theaters, charities and other performers may themselves not care - they make money on you being there. But everyone else between you and the event, they make money on your attention. They explicitly don't want you to streamline or automate event discovery and attendance scheduling. They want you to visit their pages, and be exposed to ads (whether it's regular ads where they get paid per click, or ads for different events with which they make money on you deciding to attend).
The "attention economy" is, by definition, built on making everything inefficient and full of hassle. To monetize attention, you have to make the users pay it first.
This may be an tired point, but I feel it bears repeating. The problem isn't one of technology - the tech for what you want exists, and actually worked much better in the past. The problem is businesses: they actively don't want you to use the Internet in this way.
