HN user
You're right. I want to say that openai is a viable alternative, but they're even less trustworthy.
It might be time for me to start looking into Chinese models or purchasing hardware for local llms, even if the cost amounts to 5-10k.
Cancelled. Anthropic can get bent if it wants to market itself as the ethical AI choice and at the same time lies in bed with those openly pushing for a surveillance state.
I've started experimenting with claude to run end-to-end tests for an emacs package I'm developing. It's incredible.
The way it works:
1. You start emacs in daemon (server) mode.
2. You prompt claude to instantiate an emacs client and write/run tests.
That's it.
Claude will then "pilot" an emacs instance where you can visibly see it running tests. Since almost everything is a first-class function in emacs, and emacs enables almost complete introspection, claude can debug the code in the execution environment. You can also just look at the piloted emacs instance and prompt the agent on what's wrong in the running application state.
This is much more thorough then just having claude write unit tests because many of the issues you might encounter are visual/gui things - which, again, because emacs allows so much introspection, can be examined by looking at the current application state.
This is a good example of "completing the loop."
Same here - with minor changes (mostly rebinding shortcuts), my extensively customized config works in terminal also.
Isn't this just a Bambu marketing point? I have a Prusa MK4S and a Centauri Carbon - they both print without any fuss and can be operated without any deep technical understanding.
Spreadsheets are better in theory but varsets work so much better in practice.
I'm not sure what went wrong exactly, but a common issue people run into with lofts is caused by the fact that FreeCAD tries to match vertices to vertices. If you use the split edge tool on your square to create 8 edges out of the existing 4 (maintaining the same square shape), it should loft smoothly to the octagon.
If the loft appears twisted it only means you need to change the order in which you created the geometry. FC in addition to matching vertex to vertex will also match them in the order they were created. This allows you to purposely create twisted shapes, but sometimes can happen inadvertently also.
From the home page:
Question: How do you make the illustrations?
Answer:
I get asked this more than anything else but honestly, I don't have a good answer.
I make them by hand, in Figma. There's no secret - it's as complicated as it looks.
The Advanced Edition of the book will include a tutorial explaining how I make them, where I get references and inspiration from.
The entire website is incredible. I'm amazed all the illustrations were done in Figma.
I can't tell for sure without knowing exactly what's happening, but one reason is that if you create a sketch from the Sketcher workbench, it will not be added to the active body.
If you create the sketch from the Part Design workbench, then it will be added to the active body.
A Body is specifically a Part Design concept, and FC doesn't presume you'll be working in PD, so this makes sense in a way - it works on the presumption that the Sketcher workbench works with other workbenches and not just PD specifically.
One thing to note is that creating sketches from Sketcher and PD is different. Sketcher offers attachment options to faces, edges, etc., while PD only offers to attach the sketch to base plane (XY, XZ, or YZ).
There is a good reason for this also. The reason is that in designing parts, especially complex parts, it is highly discouraged to use faces or edges (i.e., features) as attachment points because it makes your model very brittle against changes.
This is more of a general CAD philosophy than a FC thing. It's better to set where a sketch attaches based on variable values. For example, if you have a cylinder with a height 20 and you want to attach a box to the top of the cylinder - rather than attaching to the top face of the cylinder, it's better to create a variable h=20, and set the cylinder to height h, and set the box's z-value also to h.
In FC, I use VarSets for this. I used to use the Spreadsheet workbench, but found it clumsy.
As an opposing viewpoint, I also use FC extensively for designing moderately complex parts (fully parametrically constrained assemblies, dozens of parts per assembly, mechanical components involving motion).
I've also extended the functionality with python, and have heavily customized the theme and shortcuts to fit my personal taste.
I not only tolerate the software, but enjoy using it, and am quite proficient at it.
I would recommend FreeCAD to others, but with some caveats. The most important being that they need to be willing to tolerate a few hours of introductory material, and second that they are serious about using the software long-term.
Otherwise, I'd probably just recommend Onshape. But, for many others, FC is fully viable.
FreeCAD is still in active development and there was a major release (1.0) recently. There will be a feature freeze soon where the devs will focus primarily on stability and eliminating bugs.
That said, I use FC as my main CAD driver and, not only tolerate it, but enjoy using it. I had to watch several hours of introductory videos to get the hang of things initially, but now I'm quite fast and proficient.
The initial pains and common complaints about UI and such, are basically non-issues for me now and when I model, my cognitive energy is basically devoted to the design problem itself rather than issues with UI or the behavior of the software.
It's necessary to put the time into learning it, but it's worth it.
Sorry about the bad experience. If you decide to give it another try, it's worth spending a few hours on some intro tutorials first. I recommend MangoJelly on youtube.
FC is not a program you can just open and start using, especially if you have zero experience with parametric modeling.
If you're serious about design, modeling, engineering, etc., and want to own your own data, it's worth investing the hours to learn it starting from the very basics.
Some of the basics aren't immediately obvious or even hinted at very well for new users, but the "problems" that come up are consistent with its own editing model.
complaining that the sketch doesn't belong to any object
The sketch is by default attached to the "active body". Active Body is a simple, but important concept to understand. Any operation you do, including adding a sketch, is applied to what is designated as the active body. You designate the active body by right-clicking on the desired body in the object pane.
It suffers from too many "workbenches"
Another understandably common source of confusion. There's the ever-confusing Part and Part Design workbenches.
I think it's best to just ignore Part and use Part Design whenever possible. Part lets you do operations at a more granular level, but Part Design provides a lot more QOL enhancements and is more intuitive. For the vast majority of things, Part Design is more than capable. I would only use Part workbench when absolutely necessary.
You probably understand all of this already. It's directed more towards the reader. I feel the need to defend FC when certain accusations are brought up. It's immensely powerful, capable, and usable. In my case, I can work very rapidly with it - though it's taken some time to arrive here. The project deserves more than just aspersions.
Productive FreeCAD user chiming in here. I understand the frustration. It has a moderate learning curve, but the editing model forms an intuitive picture once you learn the basics and start using it.
Also second the MangoJelly tutorials. You will have a much better time if you walk through a few lessons first as opposed to just winging it and expecting to understand how everything works immediately.
I recommend starting with vanilla Emacs and just adding things as you find the need for them. Emacs comes with a lot of things OOTB. After a decade, my only essential package addon-ons are magit and yasnippet.
I have other packages installed, but they're esoteric for my own purposes.
Okay, but that is a complete misrepresentation of Prusa machines. You can buy a Prusa today and it'll spit out prints like any other modern printer. And this has been the case for a long time now. Only a small minority of people actually tinker with their machines. It seem like you're attacking a complete projection.
Are you confusing Prusa with older Enders? If you buy assembled, they just work like any other modern printer. In fact they're known for long-term reliability. If there's any detraction, it's on the basis of printing speed, price, and availability, but not on fragility.
Sounds like the classic Joe Rogan "I know a guy." rumor peddling.
It's not a lot of work, but it takes a little bit of existing Elisp knowledge. You can still evaluate plain SQL code in a buffer (sql-mode) and get most of the benefits I described, you just won't get the convenience of evaluating Lisp forms.
I've started using Emacs as a database explorer.
So, Emacs has a built-in interactive SQL mode (M-x sql-mysql / postgres / sqlite). This mode opens a SQL shell similar to what you would see in a terminal. From there, you can do your selects, inserts, updates, etc.
You can also send strings from a different buffer to your SQL shell buffer.
Now in Emacs you can very easily evaluate Lisp code to define functions, redefine functions, and execute arbitrary expressions. You can also wrap your SQL expressions inside of Lisp code. By doing so, you can take advantage of Emacs's built-in Lisp evaluation tools to interact with your SQL database.
So instead of opening a shell in your terminal, selecting a database, and writing select statements to inspect your DB, you can instead...
In Emacs, create a file called something like "sql-notebook.el". Inside that file you write Lisp expressions to execute SQL queries. To execute those queries, you move the cursor over it and just run the command `eval-last-expr` (I have this bound to Ctrl-c Ctrl-c). The results of the evaluated expressions appear in your interactive SQL buffer.
The obvious advantage of this is that you end up creating a library of often-used queries which are very convenient to execute simply by moving the cursor over the query and hitting Ctrl-c twice.
You also retain a history of these queries by virtue of them existing in a plain file, as opposed to ephemeral shell history.
Kernel version 6.8 broke suspend ($ systemctl suspend) for me. I run two machines with near identical setups. I upgrade my "preview" machine first before updating my primary machine to test for defects.
If I boot from kernel version 6.5, suspend works fine. Hold shift while your machine is booting and the grub menu will allow you to select a different kernel version.
Lisp languages seem well-suited for building games. The ability to evaluate code interactively without recompilation is a huge deal for feature building, incremental development, and bug-fixing. Retaining application state between code changes seems like it would be incredibly useful. Common Lisp also appears to be a much faster language than I would have blindly assumed.
The main downside for me (in general, not just for game programming) is the clunkiness in using data structures - maps especially. But the tradeoff seems worth it.
It's freely available on Wikipedia, UFCstats, sherdog, and tapology. You have to scrape it, but you can also find large collections of structured data if you look around.
I'm far from a data scientist. I'm just someone that has an interest in building UIs and saw a potential to look at data in a way I hadn't seen before. I'm not actively working on this right now, but if you'd like to drop a line for whatever reason, I still check my Twitter for messages when they come up.
Thanks I really appreciate that. MMA (UFC specifically) is still wide open to advantage betting because lines are often highly narrative-based. Data itself WRT to MMA is often misleading though for so many reasons (e.g., low quality of opponents presenting a skewed perception of fighter ability). However, looking at specific things is often quite useful.
The submission charts section of the site was particularly useful to me. You find that some fighters are skilled at one specific submission and that sometimes their opponents are highly vulnerable to that particular submission.
A big issue I found when trying to market the site was that, the majority of bettors have no interest in looking at data, reviewing fights, or putting any time towards making informed bets. Most people prefer to place bets naively primarily for the sake of entertainment.
A website to help make informed bets on the UFC. It presents a lot of relevant data if you're serious about MMA sports betting.
I made this during the pandemic and tried to promote it through Reddit and Twitter, but it mostly fell flat and ran out of steam. I only scratched the surface of what I intended here. The data on the site is a bit outdated since neither I nor anyone has used it in a while.
A bit bummed that it never caught on within the MMA capping community, but I've felt I could always come back to it if the potential expressed itself.
I was a really interested in BV's work for a while, but some of the major roadblocks you quickly run into once you start thinking about how to implement his ideas are that:
1. Whenever you zoom out of the code-level, you lose granularity and thus flexibility and power.
2. In order to gain expressiveness, you can constrain the domain, but again you lose flexibility to implement what you want and how you want.
3. It's difficult to avoid losing the ability to express things in general ways whenever you switch to visual or physical representation of code.
4. A lot of the ideas you might have end up being more simply represented by code, and more easily manipulated by way of text and keyboard.
5. A lot of things end up just being superficial wrappers over code. Superficial in the sense that they only hide surface-level complexity (e.g., reducing the visual volume of large code blocks).
6. Catering interfaces to novices often hampers experts.
There seem to be a lot of trade-offs. I don't know if these are laws per se, but they seem difficult to break.
What interests me particularly are new ways to create general purpose programs using methods that more efficient and more intuitive, but it seems like a really difficult task bound by near-inescapable trade-offs.
I cannot for the life of me understand why Tailwind gets so much exposure and generates so much discussion on HN. It is only barely interesting. As far as I know, all it does is wrap CSS rules into a form that can be used in the style of inlined CSS.
It's not new, interesting, difficult, or complex. I don't have much opinion on whether it's actually good or not (I happily use modular CSS), but the subject keeps popping up over and over.
Next.js recommends delivering static assets by default and is geared towards that.
We recommend using Static Generation (with and without data) whenever possible because your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request.
If you need dynamic content, they recommend server-side rendering, and lastly client-side rendering only if the page is unaffected by SEO and requires a lot of in-page updates.