Every Object in Java has a getClass method. If we changed all the static type information in Java to the `Object` type, that'd be pretty close to Python's case.
Thank you for sharing. I hadn't read that critique but I am in wholehearted agreement. Dynamic typing imposes significant cognitive overhead in exchange the privilege of letting you writing incorrect programs.
The key enabling tech is thread safe reference counting. There are many other problems that Sam Gross solved in order to make it happen but the reference counting was one of the major blockers.
There are a whole set of problems, IMHO. The code-of-conduct working-group (CoC WG) members are self selected. There is no effective oversight mechanism. No matter if you think they are currently doing a good job or not, it's not a proper way to organize such a group. The steering council (SC) did a poor job in communicating and their tendency towards secretiveness does not inspire confidence that the machinery regarding these things is working correctly. Part of the justification for secrecy is that they are protecting the banned person. That is hard to believe since it's trivial to figure out who they are talking about given their initial ban announce posting (X number of posts in a certain topic points to exactly one person). So it looks more like the secrecy is to avoid answering uncomfortable questions about the decision making and the process and not about actually protecting the accused.
Someone made a great analogy about what is happening here. You have a machine that is supposed to make toy dolls. One day you notice the dolls coming out the machine are deformed and weird looking. So, you say to the doll factory manager:
> I think something is wrong with the doll making machine.
They say
> No, this is a very high quality doll making machine, look at the specifications on the great looking dolls it will make. Don't you trust that this machine will make proper dolls? The manufacturer and people running the machine are all very trustworthy
You say:
> That might be true but I see the dolls coming out are deformed, something must be wrong.
Tim does not get a free pass to behave badly just because he is a long-time Python contributor. However, given his literal decades of civil behavior in many public forums, it is hard to believe he did something that was justifying a ban. Based on looking at what the CoC WG shared and what Tim shared, I don't see anything that justifies it. So, I don't think the "machine" is working correctly.
It took me a while to realize that the SC people were talking about in this thread was the Python Steering Committee. I thought it stood for Star Chamber.
darktable is still being developed. There are pretty regular releases. I use it as my main photo processing software (raw-based workflow).
As I said in my other comment, Aurélien has strong opinions. He felt he could not effectively work with the other darktable devs and decided to fork the project.
This is the work of a former "darktable" developer (Aurélien Pierre) who decided to fork the codebase and go it alone. He has strong opinions about the correct way to do things. I like some of the cleanup on the UI that he has done. For now, Ansel and darktable are compatible in terms of the underlying database. So you can easily switch back and forth between them. If the fork diverges significantly, it would be more difficult to maintain the compatibility.
darktable has seen some major changes in the past few years, moving away from a "display-referred" to a "scene-referred" workflow. Aurélien contributed a lot of code to make that work, most significantly, the Filmic module. darktable is not as user friendly and as polished as other commercial tools (Lightroom, Affinity, Capture One) but it is capable if you take the time to learn it.
Aurelian's youtube channel is pretty insightful. He explains a lot of what is behind the scene referred modules. And as you say, he has been driving a lot of that work. I've been using Darktable for many years for all my photo editing and it has improved massively in the last few years. He does a great job explaining how raw file processing works (in any raw photo processing tool) and how Darktable does it.
Having come across his rants on Darktable last year, I think he does have a point on the UX front. A lot of the filtering in the light table (where you organize your photos) is a bit of a mess of confusing buttons, options, and weird convoluted abstractions. I never liked that part of the software. I can work with it but years in, it remains counter intuitive how you get your files in there and manage them. It's just convoluted and weird all over. A lot of bad ideas layered on top of each other. Aurelian kind of freaked out when last year some pretty major changes were just pushed through without much debate. And I agree with him, it didn't really improve much things.
Anyway the magic is in the darkroom part, which is the part where you edit photos. There is a wide variety of modules aimed at different expertise levels. Scene referred mode is basically a big upgrade over what a lot of other packages do, which is to blindly apply pre-defined curves for cameras without much regard for the actual pixels in the raw image. Filmic and other modules do this a bit more intelligently by actually looking at the pixels, using some heuristics and working from the lowest levels of the pipeline all the way up to do the right things. It adds up to a lot less work when editing photos for me compared to earlier versions. Mostly photos come out pretty OK without much tweaking. I might tweak perceptive saturation a bit, add some contrast in filmic, etc.
Basically, the workflow is roughly: 1) tweak the exposure as needed for the gray point. Filmic adapts with sane settings for black and white points and you typically don't have to tweak that. 2) add some contrast in filmic 3) maybe add some local contrast 4) in the color balance module fiddle with perceptive saturation. Done. There are a few more things I do for sharpening, profiled denoise (as needed), etc. But that's pretty much it. One nice thing is being able to apply defaults based on rules to photos.
I might play with Ansel a bit if I can find some time over Christmas. Kind of curious to see what he's done to lighttable and the rest.
I'm not familiar with the software, but generally, I get why he left to go do his own thing. I've made a few forks of a few projects over the years considering it.
I'm perpetually in the process of beating this dead horse, but FOSS would have so so many banging gold-standard user-facing apps if they enlisted the help of experienced UI or maybe UX designers and really worked to make them part of the community. To do their job right, they need to talk to the community to figure out what their needs are, and if maintainers shrug their shoulders while the few people who speak up are skeptically bikeshedding everything they say into oblivion, then we're also going to shrug our shoulders and walk away. That's what happened to me the several times I tried to contribute to various FOSS projects as a(n experienced, professional) designer rather than a(n experienced, professional, former) developer. Often, the response you get for merely intimating that something could work better if it was set up differently is like calling someone's kid ugly.
It would be like a team of civil engineers working on a restaurant design scoffing at an architect that specializes in restaurants offering to help make an effective kitchen layout. From the civil engineers' perspective, the architect's input is superfluous and would probably slow down progress. Meanwhile, everyone else that has to interact with that kitchen suffers.
I agree with you point about UX-professionals. I am not a professional UX designer, but I work in product/graphic/web design since 20 years. As such I volunteered for an open source project once, in a push which (according to the founding developer) was of great value to the project. Basically I just looked at all things as if I had seen them the first time and tried to formulate solutions that replaces gotchas with discoverability, makes unexpected things expected, sand down paper cuts, etc.
This only worked because the founding developer was the benevolent dictator for life and I had one guy that I needed to convince. And that guy clearly was a genius in what he did and accepted that I was better than him in what I did.
Now I don't know the Darktable project's organizational structure, but given the grievances aired here I assume there is no clear shared vision and nobody feels responsible for being really in charge of the software as a tool that solves problems.
Now I am a nerd myself, but there is a kind of open source nerddom, where the people are in it for the coding first and not primarily for creating an elegant and nice to use tool. This can be okay, if there is someone in a deciding position of the project that at least cares about that aspect. If all contributers are just fiddling away in their own corners of the software you will get a patchwork of a software where different parts feel completely different.
I think that a part of FOSS culture for some developers is a backlash against the things that bother them when coding at work, and a designer having more say over how the interface works than the developer really pisses a lot of people off.
> where the people are in it for the coding first and not primarily
Oh man, you are not wrong there. The amount of pull requests and contributions I have seen that basically amount to a bit of refactoring for the sake of refactoring in FOSS certainly is higher than in non FOSS environments. Which likely has to do with there being more checks and balances in corporate software development.
I don't think i've ever agreed more with someone on here. I'm really not sure if its a case of UX/UI and art people not being willing or not seeing the demand in the FOSS community or FOSS communities to seek out those people to participate but dear god so many good FOSS projects just have horrid UI/UX because the guys doing these projects are great at backend but horrid at frontend, things like amazing AI apps just thrown in streamlit and called a day drive me nuts.
I've thought a lot about this. I think it goes much deeper than people merely not being great at interface work-- I think a lot of FOSS development is a backlash to the sort of development people have to do at work, where they're forced to reckon with designers that have more say about what the interface looks like than they do. Also, in many instances, these developers tell themselves that they are making great interfaces but they're just a little bit ugly, and people need to read the docs and get over it. Most computer users who use dozens of application every week will never read a single complete paragraph of software documentation in their entire lives. Why? Because they don't have to-- and many of these FOSS applications are doing things a lot simpler than what MS Outlook does.
Also, anybody who's been to art school or mentored junior developers knows that we get most defensive about the things we're least confident in. Unfortunately, that comes out when trying to address UI problems in FOSS projects.
> I think a lot of FOSS development is a backlash to the sort of development people have to do at work, where they're forced to reckon with designers that have more say about what the interface looks like than they do.
I think you've captured the crux of the issue and the same applies to designers too.
Say I just spent the last eight hours trying to convince a stubborn front-end developer that the reason customers complain about our UI and the product keeps failing usability tests is that it needs a UI overhaul and that telling people to "just RTFM" will not win us any new contracts.
Getting home and having a similar debate with a FOSS dev team where I have even less sway does not sound like a rewarding way to spend my free time.
Indeed it's not in the least bit rewarding. I like to pose this hypothetical to developers who seem annoyed by designers who can't do design with developer workflows. For funsies, I've styled it as a choose your own adventure story.
Imagine encountering a genuinely useful open source software project run by designers that spaghetti coded it in some node-based "nocode" monstrosity. As a competent developer, you know that you could move it to another more capable node-based system that would make it easier for them to use, maintain, and expand upon.
-----------------
a) Start asking questions to get a sense of how things worked and where they could be simplified conceptually. GO TO SCENARIO 1.
b) Fully implement a brand new architecture and submit it in a pull request. GO TO SCENARIO 3.
c) Come up with a complete refactoring proposal that shows them how your changes would affect the project in the end and make people's lives easier, and post it in an issue so you can collaborate with the existing folks. GO TO SCENARIO 2.
----------------------
SCENARIO 1: Unfortunately, that triggers the maintainers' defensiveness about their technical decisions because they're not confident in them. Then the people who have developed workflows around the shittiness get even more defensive. The real problem is that they don't have the technical depth to see how it would work in the end. Say that and good luck getting any responses for anything ever. THE END.
----------------------
SCENARIO 2: Damnit. GO TO SCENARIO 1.
----------------------
SCENARIO 3: Despite the significant amount of effort you expended, your work just sits and collects dust. You ask why, and someone who isn't the primary maintainer responds saying something about their deciding it was too much work to generating new icon sizes. You offer to automate the process. GO TO SCENARIO 1.
----------------------
Even then, having worked extensively on both sides of this dichotomy, I can assure everyone involved that the disdain some developers have for designers is astonishing, and the reverse generally isn't true. Of course there are exceptions.
Fundamentally, designers and developers have the same goal with different concerns, approaches, and areas of expertise. It's pretty ridiculous that we haven't figured this out yet.
> It would be like a team of civil engineers working on a restaurant design scoffing at an architect […] Meanwhile, everyone else that has to interact with that kitchen suffers.
> FOSS would have so so many banging gold-standard user-facing apps if they enlisted the help of experienced UI or maybe UX designers .
And here lies the rub. I have tried soliciting help in the past . Most ui UX ppl only want to work on successful projects, but successful projects don't need help from ux/UI people.
A) If you surveyed the same number of developers to contribute to the project and they said no, would you make the same inference about all developers? I think you're assuming more than you realize.
B) The number of successful FOSS projects with interfaces good enough for people who don't have a working mental model of the way software operates is vanishingly small. Firefox... though they actually have a formidable team of designers. Inkscape I'd say. But almost every successful FOSS project caught hold in the technical community, and no further. Sometimes it's barely good enough for that... I mean hell... look at Eclipse. Compare its features on paper to what you get in commercial editors and then see how many developers use it voluntarily.
C) One thing few developers understand about interface design is that adding features here and there to make things better doesn't really work like it does with, say, an API. It involves analysis, talking to people who use the software, coming up with a strategy, and implementing that strategy. Usually that strategy isn't the sort of thing you can implement piecemeal, which is why most significant UI updates today involve making a completely new design, and letting users enable the entire thing as they see fit.
> If you surveyed the same number of developers to contribute to the project and they said no, would you make the same inference about all developers? I think
This was not an assumption. You are stating a fact. I simply can't find as many UI UX ppl who are willing to work on open source..
Those I have asked reply with the answer above.
I don't know what b and c have to do with what I said though.
Not the commenter you replied to, but B seems in response to your comment that "Most ui UX ppl only want to work on successful projects". They are pointing out that even successful projects don't appear to have enough design, so the problem may not just be that successful projects are soaking up available designers.
As a professional UX designer/researcher I've found that option C is pretty common. I'll file tickets for egregious usability issues with trivial fixes, but if an interface needs to be rethought from the ground up it's not worth getting involved.
> And here lies the rub. I have tried soliciting help in the past . Most ui UX ppl only want to work on successful projects, but successful projects don't need help from ux/UI people.
Firstly, are you saying that your initial statement was solely about your own experience and not intended as a statement about designers in general? Because when you say things like "Most ui UX ppl only want to" preceeded by "I have tried soliciting help in the past" I'm not really sure how you'd expect anyone else to reach that conclusion.
> successful projects don't need help from ux/UI people
Yes, they do. Even most successful independent FOSS projects have dumpster fire UI/UX. I can't think of a single one that isn't funded and professionally managed with paid designers that has an interface or overall flow/experience that doesn't need serious design intervention. If there's an independent, volunteer-only FOSS project with functioning all-around UX that's attracting all of the design talent willing to put up with the hassle, I sure haven't seen it-- hence point b.
Indeed, point C was not a direct response to anything you said. It was a continuation of point B which described how a designer would need to be involved in a project to offer substantial contributions, and that is very clearly not the case even with many successful FOSS projects.
This is what i kinda figured to be the case, UI/UX and generally artists don't seem to participate in projects as much for free or for projects that aren't already successful where they'll get some publicity out of especially on the art side of things.
And this is one of the big problems... not what you're talking about, but your understanding of what we do.
'Art' and UI/UX design are as different as fiction writers and technical writing. Someone might be good at both, but they're definitely not the same thing. Interfaces are a communication medium, and reasoning about the best way to communicate something is a process that often doesn't even touch aesthetics. These types of designers working for larger companies probably don't even get invited to the meetings where aesthetic decisions get made, and they definitely don't work for the art director who'd be involved in that.
The first step is figuring out what problems your users are trying to solve, and the next step is working with them to figure out the most effective way to do that. It's pretty pointless when the users are insanely defensive about the status quo, as is the case in most FOSS projects.
Many UX/UI design folks I know have unpaid side projects, they're just not FOSS.
Nonprofit org websites, event posters, flyers, t-shirts, illustrations, small utility apps, WordPress themes, unsolicited redesigns of well-known applications on Dribble, etc.
I spend my days convincing developers to make UI changes. Spending my nights and weekends doing the same thing but with even less authority does not sound like fun.
I know lots of design folks that contribute to FOSS projects-- they just contribute as developers. The "unicorn" moniker for hybrid designers/developers is bullshit. You might not get a designer that's going to rewrite your embedded system firmware, but I'm a college-trained designer that was a full time web developer for 10 years.
None of the other designers + experienced coders I know contributes design to FOSS projects because the process is just so miserable. You constantly have to justify the very basic value of design contributions only to have it rejected, or completely chopped up by someone else who has no understanding of what you conceptually contributed. It's completely demoralizing.
And as a long-time developer, I get the frustration with design. Sometimes design choices seem completely arbitrary or superfluous to developers... though the root of that is developers often a) assume they know enough about design to critique it, and b) assume that design is purely aesthetic when UI/UX designers often don't even consider aesthetic concerns even if they have related training-- it's all about workflows, telling users what they need to know to solve their problems while keeping the cognitive and visual load low enough to not slow them down, and giving them the appropriate controls to do what they need to do. If your crowd is developers, then the interfaces might even look like what the developers would make-- their mental model essentially equates the GUI to a thin wrapper around a back-end API which actually does the work. To the 95% of other potential users, the interface is the tool. Interfaces are all about communication, and much the same way technical writers are way better at making end-user tutorials than developers are, designers are way better at figuring out how to communicate functionality, intent, and information to non-technical users.
Now that you mention it, I do know a couple designers who do FOSS development but I doubt they would be interested in doing design or research for someone else's project.
As someone who also jumped from development to design I agree with your description of the friction between developers and designers.
I'll also add that compromise is especially difficult when everyone involved is a volunteer, many of whom seem to be attracted to FOSS partly to reclaim some of the autonomy missing from their day jobs. And when projects become popular many maintainers are petrified of making hard choices that might anger existing users.
Given that, it's not surprising how many FOSS projects fall back to tinkering with icons and colors but otherwise recreate workflows from proprietary competitors.
A couple I'm friends with had a broken kitchen faucet handle for ages-- it would just fall off unless you held it on while operating the faucet. Unfortunately, one of the necessary connector pieces was no longer available, so it wasn't a trivial fix. Once, when I was pet sitting their rabbits, I got so annoyed by the thing that I went home and made a wooden piece to fit in where the missing part went, and fixed it while they were still on vacation. It was supposed to be a surprise but I totally forgot about it, and a few months later my wife said to them "hey do you like having your kitchen faucet fixed?" They looked at her, perplexed, walked over to the kitchen faucet, tried to pull it off, and it obviously didn't come off. They were shocked! Why? Because they were so used to holding that damned handle on the faucet that it just became an part of their using that faucet.
Similarly, people get used to bad interfaces. While we are always going to be most productive using interfaces that we're used to, that often mistakenly leads them to believe that they're objectively good. If you ask nearly any group of professional photographers how many hate Adobe, most will raise their hands. Ask them how many have used Gimp, they'll almost all raise their hand. If you ask them how many used Gimp more than once, they'll almost all lower them. Ask them why, and they will almost guaranteed cite the poor interface. While many dedicated and experienced FOSS developers (which I am) will cite Adobe's marketing practices as the reason people use Photoshop instead of Gimp, I call bullshit. You'll find many more photographers using Affinity Photo than Gimp, and considering Gimp is free, that says a lot. Who will you find using Gimp? Developers that need a photo editor. Why? They're so used to holding on the faucet that they don't even recognize when they see a properly working one. (And they'll often get really mad for even implying it needs to be fixed.) You also don't see that split with Inkscape. Most people who professionally work with vector art choose Illustrator as their primary tool, but most of them cite exactly the reasons developers assume people continue to use photoshop: overall smoothness, ecosystem integration, file type compatibility, etc. There are some legitimate shortcomings in Inkscape-- the type tools are just not as good which matters for graphic designers, for example. But lots of people who do vector art professionally do use inkscape.
Planning on it. I'm compiling a list of points and counterpoints I've encountered when discussing this over the years and forming it into something informative that has practical actionable advice for everyone involved.
On the flip side, coming from Darktable and trying out Lightroom felt like trying to do good old darkroom work with my hands tied behind my back.
Darktable offers a few really powerful, generic tools that you can use in different ways to get different effects – things like equaliser, parametric masks, LAB curves, etc. It makes little sense to use it without reading up on some of those more advanced tools first.
Lightroom, in contrast, focuses more on offering a small selection of pre-defined tools for specific purposes. But once you want to do something outside of that (parametric masking is one of those things I really missed) you're shit out of luck.
You are most likely both right, because it mirrors my experience everytime I look at Photoshop/Lightroom when my dad does things and when looks at darktable when I do things.
Would you mind giving examples where you use parametric masking? I read the docs* and it is not very clear to me the practical side (I'm a Lightroom user).
An example: Camera noise is often particularly annoying in the sky area. So I'll have two denoising filters active: A subtle one that doesn't lose much detail, and a strong one that only applies to the sky. Selecting the sky tends to be easy with a parametric mask: Just select the sky's hue and it's done.
It’s not stellar, but it doesn’t suck, and I haven’t been forced to upgrade.
Maybe I will never migrate off LR and just create a new catalog on some other computer with Ansel or something.
I use the last version of LR6 one could purchase outright, and I dragged it kicking and screaming all the way into Ventura, but I’m sure the party well end pretty soon.
But as a Darktable user, I found the implementations of strong opinions frustrating because I value actual workflow above potential technical superiority.
Display referred worked fine for me because the important work happens before the shutter is clicked. The skill I want to develop is fixing things in the lens not fixing them in post.
Breaking changes suck.
But again open source developers don’t owe me anything.
I don't disagree, I spend a lot of effort thinking about things at exposure-time. I think the thing that sold me on scene-referred is that I started conciously thinking about the kind of data I was capturing. It's often the case that the display medium, or its artistic representation, has a much lower dynamic range than the sensor in the camera, and so there are a number of things you can do to get the most data possible when capturing to leave yourself room for expression at presentation time.
What this gives you isn't necessarily the ability to "fix" things in post, but the ability to decide how you want your image presented in a certain medium or format when "developing". Even master photogs like Ansel would take liberties when developing to realize their vision from the negatives they were able to capture.
For me, I have intuitions of the relationship between my printer and my screen from experience.
And I run test prints and reprint if I don’t like the way it prints.
I mean since you mentioned Adams, for Adams the print was what mattered…the print is the title of the last of his three books series.
Kodak doesn’t change HC-110 every six months because doing so destroys value.
But again it’s his software. I just wish he weren’t so bored as to invent problems to cleverly solve and solutions for which he may argue.
The legacy editing workflows are generally, if not entirely, still available in Darktable. I haven't yet encountered a defect in my old edits on new versions of Darktable.
It absolutely is, it is what I use for RAW developing and post. Does everything, does it good and is, above all else, non-destructive.
It is, at least of I go by my dad who is a Photoshop veteran, quite different to what he used to.
The only things I could see as, if I am really really critical, are:
- sharpening, usually decent enough but SharpenAI from Topaz is another league. As I said, good enough for all except the edge cases
- de-noising, same as sharpening, astro-denoise works like a charm so
- masks, which I haven't really figure out yet, so my problem and not darktable's, Lightroom and Photoshop seem a tad more intuitive so
One thing I'd love, but again maybe I just didn't find it yet, is the possibility to export the database of picture edits. For now, I have darktable create dedicated files once a photonis edited and I make back-ups of those. I did loose edits for around 100ish photos due to some unrelated issues which required reinstallation of darktable so, which again was on me for missing darktable stopped creating said files after an update. Being to just dump the darktable database of edit data would be really nice so.
Summary, I can only recommend it. Especially for people starting post processing, the learing curve for each software is basically the same after all, and without prior knowledge they wont recognize any differences.
> "Ansel is what Darktable 4.0 could have been if its developers were not so busy turning it into an usability nightmare. Ansel is a Darktable 4.0 variant where 30.000 lines of poorly-written code and half-broken features have been removed, and 11.000 lines rewritten : it runs faster, smoother, uses less power and requires less configuration. Enjoy an app focusing on getting work done and stability."
This opinion comes from a former pho photographer, one who desperately wanted to love Darktable...the shots are warranted in my opinion. Darktable is a complete car crash of poor usability and militant contrarianism on established user experience design.
It has so much promise but the 'lead by committee' approach just resulted in some kind of collective 'demand avoidance' from the devs who seem to revel in delivering an unusable product. And I mean unusable for those not willing to learn an entirely new paradigm of interacting with a piece of photographic software and dive into the docs for everything, including stuff as silly as a keyboard shortcut or move between modules.
I've yet to read all the Ansel blurb but I'm pretty sure this is from the guy who's made the most improvements to Darktable in recent releases. So it's incredibly exciting to see.
I doubt it'll get any DAM capability though, even for a fork that is asking too much :-)
As a darktable user, I have to say none of that would motivate me to switch.
But then I care about the results, a nice picture to print or look at on a screen, way way more than about the tools used to get that result. Goes for cameras and lenses and whatnot as well.
You can make due with only a couple of good knots. Very short list: the reef knot (square knot, avoid the granny version) and the alpine butterfly (don't use reef knot for joining two ropes, i.e. a "bend"). The alpine butterfly is more useful to know than the bowline, IMHO.
If you want to expand your list a little, here are some additional useful ones: double fisherman's, adjustable grip hitch, sheet bend, trucker's hitch.
Edit: I suppose this is more useful with a little additional commentary. The reef knot is so common that you should know it and know how to avoid the granny knot and also when not to use it (e.g. as a bend). You can use the alpine butterfly as a bend and also for quite few other things. It is more versatile than the bowline (e.g. if you need a loop that doesn't slip) and works fine as a bend (very smiilar to the Zeppelin bend).
Right, but this isn't a what question, it's a when to do what question. I might know a knot, but I don't know when to use that knot and when it ought to be avoided. That's what I am getting at.
Even under the "bend" page in Wikipedia, sometimes the knots are merely described.
I would first have to know what I was doing. Which I do not.
I might be able to make the flowchart if I understood knots; I might be able to understand knots if I had a flowchart. If we had ham, we could make ham and eggs, if we had eggs.
If it's a safety critical situation, leave it to the experts/become an expert/try to make it so that the failure of your knot won't kill anyone/etc.
For non-critical use(In my limited experience, some of my choices are as much about ease of tying as actually picking the right one, some of these are things I've only used once or twice or never used for anything important):
If you want to tie two ropes together, use a sheet bend. or a double for more security, or the slipped version to be able to undo it. Add a stoper knot for even more security.
If you want to make a loop in the middle of a rope, alpine butterfly.
If you want to adjust tension, tautline hitch.
If you are tying thin spectra cord, or making a permanent attachment between thin cord and something else, try a uni-knot. Note that it's not actually considered the standard for tying to carabiners, but I use it sometimes(For non climbing purposes).
If you are tying a bundle together, try gliepnir or a standard shoelace knot, or a clove hitch.
If you are tying a rope to a fixed pole, try a clove hitch. It's not perfectly secure. Maybe try gliepnir too. Honestly bundles and hitches are the two uses I'm least sure of. There are apparently better things than the clove hitch, but it's easy and good enough probably.
If you want to tie something you can undo really, really fast, use a highwayman's hitch.
If you want to tie something someone else might need to untie, shoelace knot which is a doubly slipped square knot, it advertises visually that it's meant to untie.
Might want to just use a regular overhand though, the Ashley stopper is hard to undo.
If you want to cause a real nightmare for anyone untying something, or remove unwanted fingers by circulation loss, constrictor knot.
If you want to make the end of a rope not go through a hole, Ashley stopper. You can also use this, or just a simple overhand, to keep another knot from slipping.
If you want to do something involving climbing, do not listen to me, I know nothing about it.
The 41C came out about 10 years before the 42S. Each would have their fans. The 42S doesn't have the hardware expand-ability but is generally faster and a bit more refined. If I wanted a nice handheld calculator today, I'd prefer the HP-42S or the Swiss Micro version. However, Swiss Micros have a 41C clone as well, if you prefer that.
The 42S was also mostly backward compatible with programs written for the 41C, intending to be its modern replacement. It did have an IR connection for some expandability (this was pre-USB era).
I'll also note that, with regards to using an HP42S today, most of their LCD screens have not aged super well and have faded a lot. Other models like the HP15 and HP32S(ii) have LCD screens that seem to age a bit better for whatever reason (potentially the support for the menu and limited graphing behavior of the 42S required some slightly different LCD parts). I have all these models, but wouldn't recommend an original 42S to anyone but a collector due to screen visibility issues - my HP15C and HP32S are plenty usable still though.
I also highly recommend the Swiss Micro replicas if you like RPN calcs. Very solid attempts at reproducing and modernizing some timeless calculators.
Nothing insurmountable. You need a receiver that supports RTK. Typically the hardware receiver can do it but you have pay to unlock the functionality (typically about 3000 USD per device). You need an RTK base station (or one you can use that's not too far away) and a way to get the correction signal (local radio system or over Internet with cellular data).
With DGPS corrections, like you get with the satellite that failed, you get about 10 cm positional accuracy. For dryland crop farming, that's often good enough. It is more accurate than what most human operators can achieve and reduces operator fatigue. So many ag GPS systems are setup to use it out of the box.
There are other solutions, in addition to RTK. Trimble has "CenterPoint". There are Omnistar corrections (different sats, better accuracy than DGPS). Novatel has "GLIDE" but I've never seen it in use.
