Thanks! I know, it's totally possible to create beautiful apps using Qt. The problems are:
1. Most people in OSS don't care about UX and aesthetics (most of the people using Qt)
2. The Qt Company's examples are absolutely ugly (with the exception of one). If that's what you show developers they would either not believe it's possible to create beautiful apps with it or that it's too hard.
> On Windows, that usually means you need to open up the MSVC x64 native command prompt and run llamafile there, for the first invocation, so it can build a DLL with native GPU support. After that, $CUDA_PATH/bin still usually needs to be on the $PATH so the GGML DLL can find its other CUDA dependencies.
Yeah, I think the setup lost most users there.
A separate model/app approach (like Koboldcpp) seems way easier TBH.
Author here. llamafile will work on stock Windows installs using CPU inference. No CUDA or MSVC or DLLs are required! The dev tools are only required to be installed, right now, if you want get faster GPU performance.
My attempt to run it with the my VS 2022 dev console and a newly downloaded CUDA installation ended in flames as the compilation stopped with "error limit reached", followed by it defaulting to a CPU run.
It does run on the CPU though, so at least that's pretty cool.
I've received a lot of good advice today on how we can potentially improve our Nvidia story so that nvcc doesn't need to be installed. With a little bit of luck, you'll have releases soon that get your GPU support working.
The CPU usage is around 30% when idle (not handling any HTTP requests) under Windows, so you won't want to keep this app running in background. Otherwise, it's a nice try.
I'm sure doing better by windows users is on the roadmap, exec then reexec to get into the right runtime, but it's a good first step towards making things easy.
I've realized recently that (for me) mouse interactions come more naturally for more exploratory or creative work. I'm happy with my mouse! and yet for straight coding, or writing, I would rather keep my hands on the keyboard. It's fun to get good with all the tools(toys)!
Came here to say similar. In particular dhall does allow scripting (functions etc.) but is non-Turing-complete as a feature. This seems like a particular sweet spot to me as it allows for more dynamism than data formats like json/yaml while constraining the scope sensibly.
It also has very nice bindings with haskell and nix
It allows each line to be completely independent of it’s neighbors; you can comment and/or add lines without needing to touch neighboring lines. Also, it makes it visually easy to spot missing commas. Give it a try sometime, it’s actually quite nice.
Having prefixed commas is a rather common style in the Haskell community, because it ends up nicely matching open/closing brackets/braces and lining things up.
Since the author of Dhall comes from the Haskell community, he's kept this style.
How does this compare to something like Buildbot (https://buildbot.net/) - I share a lot of your frustrations with Jenkins and this is where we landed.
I don't know, I'm really not trying to make one of those cliched checkbox X vs Y type grids, but when I started building Vespene I was most concerned about being able to make builds more consistent when you had hundreds of microservices developed by a lot of different teams. This is why I did http://docs.vespene.io/variables.html#snippets
I also saw a lot of people trying to do ops style stuff from tools like Jenkins, which is why Ansible has built-in SSH automation so it can hold on to SSH keys and use them in your behalf, and has some really cool built in RBAC so you can decide who can run what and it can be different than who can edit what.
Mostly I just want to build an architecture that can go interesting places - what is here today I think is usuable, but it's just a starting point. My thinking is if you make an architecture that is really pluggable, and the code is easy to read and add to, it can go to some really neat places.
I'd just recommend taking a look at the various chapters of http://docs.vespene.io/ to get a feel for features, and if you like it, spin up a copy using the setup instructions and see what you think.
Snippets of stuff is really missing from a lot of platforms. I use gitlab to store parts of our builds in one location instead of duplicating build code in every repo (and we have lots of them) for stuff like building RPM, where they all use a common model. Making this first-class is a good move.
Hello, Community Advocate from GitLab here. Thanks for sharing your solution with other users, we are happy to hear how you use GitLab to make your work more convenient.
Configuration management is best with operating system packages, so in creating "Ansible", not only did you completely miss the ball, you created a monster. People now hack ad hoc YAML files instead of designing clean OS packages to manipulate the configuration.
It's fine if you don't like it - there are things I don't like about it, but ultimately single packages can't express multi-node configurations very easily. We need something.
While I "grew up" as it were, believing in RPM, we live in a very post-distro, multi-language kind of world, and there's a need for things to glue that together. How many times have I tried to campaign against "wget tarball" as a deployment mechanism, I don't know. It's rough and yes, there's a lack of discipline in ops that needs to improve.
Immutable systems is a VERY interesting way to solve that, but it doesn't work for certain stateful things and you always need something to deploy the undercloud.
I'd encourage you to try to build your own experimental project to try to find different ways to do it, as this is the only real way that technology ever gets ahead.
Funny you should mention RPM's, since that's one of the packaging formats we perform configuration management in.
I have my own configuration management framework which can add and remove configuration from files that each package brings on. It's written in AWK. No knowledge is required to use it - configuration packages deliver just their configuration files' excerpts. In addition to being able to template them with regular shell variables, self-assembly is supported as well.
How is that different than what Puppet, Chef, CFEngine, or any number of other configuration management tools do [and did long before Ansible]? How do you propose to have a package that requires dynamic configuration supplied by the system (something from dhcp, for example). Are you conflating package management and configuration management? I'm genuinely curious.
It's not any different, they all suck. Read my reply above to the author on how it was solved cleanly without needing to hack anything, just deliver a config excerpt via an OS package and it works. It's not open sourced yet, mainly due to lack of spare time to spend on computers and my cronic exhaustion.
The first proof of concept prototype was developed in 2007 based on insights gained with packaging and system engineering at two different companies, one a software one and the other a very large financial institution.
Refined framework (oh how I hate that word now thanks to web developers!) went into production in 2009 on Solaris 10, depending on advanced AT&T SVR4 packaging features. It was then subsequently ported to CentOS / RHEL RPM and went into production around 2011. It's been the corner stone of configuration management for the entire infrastructure, particularly production ever since.
Ugh. Conveying tone on the internet... I mean it sincerely: I do wish you good luck. Please about your project on HN when you release it, I'd love to see it. While I think it's deceptively hard, but config/immutable state are fascinating areas.
I think we owe Jenkins a TON of credit for being a free solution that has a lot of great traction.
I'm used to seeing pages of checkboxes and can't stand how obscure some of the configuration is, but mostly I wanted to write something that could handle configuration differences between hundreds of projects, so that is why there are things like Snippets in Vespene.
Plus, I wanted to make something that was a little better for ops use cases (so people don't also have to go pick up something like Rundeck), so that's why there are things like the SSH integration and http://docs.vespene.io/launch_questions.html
It's more about capabilities and future capabilities than the frustrations IMHO.
Though I do have a bunch of friends who are frustrated with plugin compatibility, plugin hunting (we're doing more of a "batteries included" approach like I ran with ansible - just with much less modules), and stuff like that.
I was also able to add in some stuff like container build isolation really easily, and that's all included stock.
I've used https://www.letsgaze.com/#/ a few times which worked pretty well. Only works with files you have access to, or freely available youtube content though.
I agree that it's a neat idea. I'm sure the content problem is why there aren't more attempts at the moment.
And if you want an idea of the type of 'generated stories' it can tell, you might be interested in http://lparchive.org/Dwarf-Fortress-Boatmurdered/ - a "Let's Play" told by successive rulers of a fortress. (The story proper begins in Update 2 of Thread 1)
Warning, you may spend the rest of the day reading it...
Another warning: You'll never look at an elephant the same way again after reading this. I used to think they were intelligent, noble creatures. Now I know the truth.
Just commenting to say thanks for mentioning the bongos! My house-mates thought I was mad when I bought them as a student, but it quickly turned into a house favourite. I would still recommend them to this day if you can get your hands on them.
Re: flow-state - perhaps the only game where this is possible at any level of intoxication.
