sinker
They haven't abandoned society. They are trying to improve it. I don't understand the solipsism criticism. It seems specious. There's a clear philosophical drive:
No they don't. We're not talking about lemonade stands here.
Business owners don't have a choice. They must use CC processors or else lose their business. That's the point.
You're shoehorning a philosophical definition of freewill into a context where it doesn't apply.
Given that consumers and businesses have "freewill" or "freedom" to make any financial decision, then by your logic there are no bounds a company can possibly transgress.
Why do you think we have anti-trust laws, or consumer protection laws, or the FDA, or have litigated against monopolies in the past, or have the host of many other things which protects consumers from being taken advantaged of?
> If Visa and Mastercard didn't add more value than they cost, then merchants wouldn't accept them.
3% of transactions is an incomprehensibly large amount of cash. The systems that exist to transact cash have been in place for decades already. Major countries have already developed their own payment systems because they understand the problem and the cost to society. Most of these are entirely free and AFAICT, they work just fine.
> for example by competition
Sure, if you set up a time machine. Even in that case, there would be no meaningful competition. Someone else would simply occupy the position in the middle of the intersection instead.
"Parasitic" and "toll collection" remain accurate descriptors. What about "entrenched" and "monopolistic"?
Consumers shouldn't have to pay a fee to give someone money. Sellers shouldn't have to pay a fee to collect money. Security should be built into the system, not a luxury you're taxed for.
They should not be able to tithe all of society in perpetuity because they set up shop decades ago.
See also: the app store, telecoms, health insurance in the US
Overall, the "rhythm" is a bit off. The user should know what they're seeing even before they see it, at least conceptually. The design/layout doesn't section off dense sections from skim material. Front pages in general should be built for skimming rather than deep consumption (scanning). Scanning should appear optional visually.
There's a lot of "scan" material, but users who visit your site mostly just want to know what they're looking at - at least at first. So the deep material kinda just gets in the way of actual comprehension.
Another critique: too much visual uniformity. Every major section looks the same (poor "rhythm"). This leads the eyes to glaze over much of the site.
It sounds dumb, but our eyes don't "read" a webpage, we "see/feel" it instead. We see structure, layout, differences in colors, font sizes, patterns, bold headings, etc. We ignore the actual textual content. We only do actual reading when we're hunting for something specific (eg, a specific nav link).
The aesthetic itself is fine, but the layout and structure need work.
It also helps to learn upfront the idiosyncratic terms and concepts like buffers, windows, frames, yanking, killing, etc.
Most of these terms map one-to-one to more familiar nomenclature like copy, paste, etc.
Buffers is a concept a bit more unique and integral to emacs. It's easier to understand in practice than in reading.
Most importantly though, emacs is a lisp machine, and exposes the highest level of granularity, and enables the finest level of customization for the user.
In emacs, everything is available, everything is a primitive function, everything can be inspected, the documentation (ie, contextual food for agents) is built-in, and emacs itself can be piloted entirely through function calls. This means that agents can fully control an emacs instance and run that closed loop (write, test, evaluate, repeat) with almost complete information - which makes the [given prompt] : [results conforming to spec] relationship much tighter than in most environments.
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.
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."
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.
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.
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.
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.
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.
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.
> 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.
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 have other packages installed, but they're esoteric for my own purposes.
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.