I did not find it very had to relearn the difference in bindings. Quite a lot are actually the same but one big difference is the selection before action rather than vims movement then action. Which IMO I find the helix way nicer after using it for a while. Never really lost the ability to use vim either and I can switch between them with relative ease. Though I do miss the helix way of working when I am forced to use vi input on things.

Not in any bothersome way. But if you really want to reinstall often that is valid as well. You can very easily script the arch install process to get you back to the same state far easier than other distros as well. Or you can just mass install everything except base and some core packages and reinstall the things you care about again which almost gives you a fresh install minus any unmanaged files (which are mostly in home and likely want to keep anyway).

Any major Linux distribution has a system for building packages

I have built packages for all the major ones. Non arch packages are a pain to build and I never want to do it again. In contrast arch PKGBUILDs are quite simple and straight forward.

How can you trust code with root access to the system just because it’s in the aur repository?

Because you can view the source that builds the packages before building them. A quick check to not see any weird commands in the builds script and that it is going to an upstream repo is normally good enough. Though I bet most people work on the if others trust it then so do I mentality. Overall due to its relative popularity it is not a big target for threats when compared to things like NPM - which loads of people trust blindly as well and typically on vastly more important machines and servers.

I use it precisely because it doesn’t break all the time and is less restricting… Don’t know where you got the idea it is not.

I’ve tried NeoVim but I really don’t want to waste time doing text-based configuration and messing with extensions just to get some basic features working.

This is the reason I switched to helix. Comes out the box with what you would expect so you dont need 10s of plugins and 100s of lines of config to get a base line experience.

Well, that is how bubbles form. People will stop investing while/after it has burst. That is basically the definition of a bubble bursting.

But it increases investors likelihood to invest… That is all that really matters these days.

What non-profit company did you get the computer you are currently using to type these messages from?

There is a big difference in planning server layouts and similar tasks and writing pseudocode. In comparason the planning is much cheaper and the cost of getting things wrong can be quite high. But with pseudocode, it is not that much cheaper to write than real code is, it gives you a lot less useful information and the cost of a mistake is quite cheap in code (that is while you are still developing things and for the types of problems pseudocode might even be able to catch).

By “forever” they mean you will be paying them forever for the privilege of using the mouse. Unless you break it that is, or they feel like they no longer want to support it at which point it will likely become a forever brick.

They said on a linked post:

Make fish available on servers that run old LTS distros Making it easy to build and run

Which suggests to me they are using features from newer versions of libraries then exist for older LTS distos. Making it hard to compile and run on them. Most of rust libraries are statically compiled so that is not an big issue for rust. Though this is just speculation on my part.

I just got a Sovol v8, using it with orca slicer on Linux without any issues. Orca slicer has a GPL license. Sovol v8 is based on the voron v2.4 printer and sovol have released the source and 3d files for the v8: https://github.com/Sovol3d/SV08 and its firmware is based on the open source klipper firmware. So overall is quite an open designed printer. Those are the big reasons I went for it and would highly recommend it if it is within your budget (which gives you quite a lot for its cost).

But quite a lot of printers use and/or are compatible with most popular slicers of which most are open source. I think bamboo labs printers are the major one that is not open by design. Though I admit I have not been that emersed in the available printers in recent years.

Went hungry is a bit of an understatement… I went hungry yesterday because I forgot to eat lunch. The other term they use later on ‘facing chronic undernourishment’ describes the problem a lot better.

Nah, if you have some complex logic you are not sure about then you need to see it run to be able to see how it reacts to changes. You cannot run pseudocode so it is far harder to validate it will do what you want it to do.

I fundamentally disagree with pseudocode and all the arguments made out on this um, paper? It is written by a educator who has seen lots of shitty unreadable student code which is about the only time pseudocode makes sense to write. But even then, if they cannot form what they want in code what makes making them form what they want in words any better?

But spending ten minutes to think out carefully the pros and cons of different approaches to the goal can save you hours of time debugging and refactoring your code later on.

I find the opposite. Spending time writing pseudocode leads to far more time wasting on things that don’t work. One of the biggest problems with pseudocode is YOU CANNOT RUN THE CODE. Not until you have fully finished thinking about it and then converted it to actual code. Only then can you tell if the code even does what you want. No, far better to write a small segment of code and then incrementally build and test it little by little. Then I can verify my ideas are taking me in the right direction and not resulting in some weird behavior due to some broken assumption I made early on.

Incremental development is the way to go. Just test things as you write them. Don’t write the whole program (and then rewrite it again in an actual language) before you ever even run it. Write a small bit, test it, refactor and continue. You cannot do that with pseudocode and it is vastly harder to debug something that is complete rather than incrementally checking it at every stage as you progress.

Pseudocode makes low-level design reviews easier and reduces the need to review the code itself.

No, no it does not. You NEED to review the source code to see if it does what the person thought it would do. This step cannot be skipped. So what value does pseudocode add then? The code should be readable enough on its own without basically doubling the amount of lines you need to read. Plus NO ONE READS COMMENTS. This comes from 15+ years in the industry. More often then not I see comments that are out of date and no longer describe the code they are talking about. It is a lot of effort to keep comments in sync with code and not worth the effort. There should be no pseudocode comments in your code at the review stage.

Pseudocode supports the idea of iterative refinement

Iterative refinement is vastly better when you get feedback on what you have written. The best place to get that is to run the code and see what it does (either manually or via testing). You cannot do that with pseudocode. Only hope that you can spot a problem, which more often then not you will not. If you write actual code you can run it and see if it fails and how it fails.

Pseudocode makes changes easier. A few lines of pseudocode are easier to change than a page of code

That is a false comparison, why would you only have a few lines of pseudocode and a whole page of code? Surely your psudocode will roughly match the number of lines of actual code? Otherwise what is the point in it and how will it help you spot any problems? You can always write real code as a series of function calls to hide away the implementations if you want a similar approach.

Pseudocode minimizes commenting effort

Not writing comments minimizes commenting effort. Comments should be used sparingly to describe things that cannot be describe in code. IMO the only comments worth while (at least ones that are not doc blocks) are ones that describe external factors. Like “this is to work around this bug <link to bug report>”. Or “we tried the more obvious solution here X but found it caused problems Y” or “this is actually required due to this weird undocumented behavior”. Comments that just describe the code are a waste of time and effort as you now have your code defined twice. Once where people will read in the actual code and once where people will ignore and will slowly rot and worst start to lie. The number of times I have seen a comment contradict the code and have no clue if the code or the comment is right… More often it is the code that is write and the comment is hideously out of date. That just becomes wasted effort trying to figure things out.

With other approaches, design is separated from the code, and when one changes, the two fall out of agreement… As long as the inline comments are maintained, the pseudocode’s documentation of the design will be accurate.

That is a big if there, IF they get maintained. Which they wont. It is far too much effort to edit the code twice. No one wants to do that and so no one does do that. Just read the code if you want to know what the code is doing and reject PRs for code the is unreadable.

The only people I ever see arguing for psudocode are professors that have never worked in the industry and spend far more time reading crappy students code than anything else. I have never seen anyone actually do this in production systems.

You can have backups of physical books. Just copy the text from one to the other. Yeah it is manual work but so is writing the first one in the first place. You can then store the second copy in a fire resistant safe or at a friends or family members house (maybe inside a safe as well).

Yup, and loads of people driving to the store will pollute more then one truck delivering to those same people.

If only cities were walkable and had good public transport, then deliveries would be worst.

I just gotta figure out how you subtract material and it increases surface area.

Say you have a smooth shape like: ███ That has a nice and simple area and surface area. But if you take a chunk out of it: █▂█ you now have less area, but surface area is the same plus those two new vertical walls - so it has increased. That is basically what roughing up the surface does. Might also do some deformation and add some peaks as well though far less than the material removed.

This all leads into the coastline paradox and fractal patterns which show that you can have a finite volume surrounded by an infinite surface area. Here are some interesting videos on the topic: https://www.youtube.com/watch?v=AD4vPNBSrKY https://www.youtube.com/watch?v=I_rw-AJqpCM https://www.youtube.com/watch?v=gB9n2gHsHN4 https://www.youtube.com/watch?v=3s7h2MHQtxc

Perhaps the roughing up of the area permits for micro-gaps which allow for the two to better stick?

I think it is more to do with increased surface area - more molecules of the glue are in contact with the part.

That should not break things though. Maybe get a merge conflict that you need to sortout at worst. This is essentially the constant state of working with other people on a project.