161–170 of 181 posts
Earlier quoted context omitted.
Stallman performs the vital function of pinning the Overton Window to the left, which benefits those of us with more nuanced views. I'm not going to run my own mail server in 2023, etc.
> I'm not going to run my own mail server in 2023, etc. But many do. It’s still not that hard.
I've been writing services... as libraries first. Then just wrap the library in a very simple `main()`: ``` #include "servicelib.hpp" int main(int argc, char argv) { return servicelib{argc, argv}.run(); } ``` The library can be re-used in other apps or services. Then the whole damn library is unit-testable with any arguments you throw at it. Got an OS where argv may be null? You can unit test that. Got a user who dec…
That said, the lib first approach was made a goal in clojure land, and sometimes it adds some choice/integration fatigue.
Earlier quoted context omitted.
Some people don't think like that when they write software. They view it as a knife, not a noose. I prefer those people.
I'm writing from the perspective of the user (which may be a developer using your product in their product). I don't really care if you view software as a knife or as a noose, I don't want to be coerced by the threat of either .
It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…
This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice. This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are eithe…
Selling more is how service providers are able to sell their generic service at a lower price than the cost you would incur by building it in-house. In other words, being forced to upgrade to accommodate features that other users want is the price you pay for sharing the development cost with those other users. That's not shady.
- Libraries are suitable for providing building blocks and common functionality, that you'll build your system on top of, that systems will depend more heavily and execute more frequently.
- Services are a strong choice when there's a need to abstract high level operations and architectural complexity. Your system can then focus on making high-level calls without the burden of operating and managing all components and dependencies involved.
I will always remember a relatively large GUI application... one big EXE project. All content was hard coded inside Windows/Forms, Button Click methods, etc.
I started to break the GUI app down into smaller components. OK.. It has (A), (B), (C), (D), etc. Started to build isolated libraries. I could then test it without having to run the GUI app and get to the respected Window, etc.
It made life sooooooooo much easier.
Now, it was a bunch of libraries which the GUI apps includes and wraps with presentation. The great thing is that we need to upgrade our tools, opening the door to using a more modern GUI -- as everything is in their own library.. this becomes so much easier to do.
This was a C# application using WinForms using .NET framework (v4 something). We upgraded to .NET Core. Once the libraries had upgraded, we decided to use WPF. It was a relatively pleasant experience. Now imagine trying to upgrade .NET version + WinForms to WPF as it currently stood -- all scattered inside the GUI app.
My default is to create as library first.
Earlier quoted context omitted.
Where did you get a 3 order of magnitude difference? Are you still using hard drives for your storage medium?
Adding two numbers together takes on the order of a nanosecond. Doing the same thing using a rest / http service (like an idiot) in the same datacenter takes on the order of a millisecond. Six orders of magnitude actually.
For the comparison being referenced here, if you want to compare RAM, the storage medium that backs compute, to modern persistent storage, here it is:
* 40 GB/s per DIMM vs 5-10 GB/s per NVMe SSD. At most one order of magnitude off, but you can pack enough disks into a computer that the throughput ratio is almost 1:1. AWS EBS is about 1 order of magnitude different here, and that is with network-attached storage.
* 100-200 ns latency (RAM) vs 10-50 us (fast SSD) - about 2 orders of magnitude, but also possible to hide with batching.
Earlier quoted context omitted.
We usually wrap a set of valgrind debugged small test/demo programs that hammer a library to monitor for leaks etc. However, ensuring thread safety can sometimes be a challenge. =)
We run unit tests with ASAN. Good test coverage gives us good confidence in safety. I recently picked up a subscription to undo.io and I figure the next time I see any problem then I'll take that for a spin. I've seen trouble with gRPC and trying to debug it is infuriating.
I wish they used Erlang/Elixir/Phoenix channels to reduce the system complexity,
https://dev.to/codecast/how-to-use-phoenix-channels-18k9
Sometimes we just need to keep a system running, and quietly replace it with version 2 later... Yet later usually never arrives... lol =)
It's all fun and games until you hit version n+1 or n+2, and often realize how slow many customers are to upgrade the library. Then there are the potential conflicts in your own dependencies. And let's not forget the occasional breaking change you introduced. You are now sacrificing the money saved by not hosting to maintain what will likely be a growing matrix of possible versions, underlying assumptions, and my per…
This is a completely broken model. You are wrong by pushing your changes on "slow to update" customers. Customers know when to update much better than you do. If you are trying to update before they want to, you are doing them a disservice. This attitude is inspired by the desire to sell more, and often times, it means to sell more unwanted crap, where customers are trapped by the "package deal", where they are eithe…
I invite you to review roll outs of security updates. These are rarely about pushing new features, and may have nothing to do with my own code at all. It might just be a version bump to my dependencies config (if a dep manager with shared libraries is involved), or just a refresh of my flatpak equivalent. But, either way, shit breaks in weird and wonderful ways, and there is little I can do but wave my arms frantically at customers.