sinker

You're missing the point completely, not just of this exchange, but of the entire thread. It's not about the relationship between businesses and customers. It's about an entrenched system which parasitically drains the consumer, benefiting the few at the cost of the many - and the health of the economy (read: society) as a whole, and why this system persists because it's interlocked, not because it's fair or beneficial. Read some of the other responses to understand.

> But i gotta say, living off grid is fundamentally solipsist. Abandoning society rather than attempting to live well within society will always be a dead end.

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:

https://100r.ca/site/about.html

> "Many of them refuse to accept CC payments"

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 merchants didn't accept them, they would go out of business. How is that not obvious? Technically there a choice. In reality, you have no choice, and no recourse, and you can't outcompete these companies either. The idea that you can just decide to block CC payments and survive is fantasy. You're essentially signing a death warrant for your business. That's not any meaningful form of "freedom."

> If Visa and Mastercard didn't add more value than they cost, then merchants wouldn't accept them.

https://en.wikipedia.org/wiki/Just-world_fallacy

> significant costs to provide

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"?

Credit card companies are essentially charging a rake on the consumer economy. They provide a valuable service, but skimming every transaction and funneling it into a handful of private companies is a net detriment for the vast majority of society. They've been at it for decades. First-mover advantage. Entrenchment effect. When CCs are integral to the transaction of money, it's essentially a tax on exchanging money. It's monopolies conducting parasitic toll collection.

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

It's not too readable. It would benefit from a columnated layout. The fold is also too long. It should be an introductory block.

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's no different from learning vim. Just stick with it until the shortcuts become cognitively automatic.

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.

Emacs is incredibly powerful with ai agents. Because everything is a function, and emacs is introspectable down to its atoms - agents can write, review, execute, and evaluate the results in a closed loop. The evaluation part is usually what's missing from most agent-driven workflows. Either you (the person) needs to do a live evaluation or the ai agent derives a primitive evaluation using what's available (eg, screenshots, looking at html/css output to form a visual representation).

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.

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.