There have been third party clipboard managers forever in windows, which is kind of funny because that is almost more like the unix philosophy than expecting the UI system to handle it all.
Klipper was entirely a different program, process, etc. that was using the system tray. Nowadays it seems to be a plasmoid in the system tray. How can that be less of a UNIX philosophy than the Windows alternative? Because it’s developed by the same community that makes the shell? That doesn’t make sense to me.
Then it’s not really an apt comparison as the two are comparable. I had assumed based on context we were talking about our of the box functionality from KDE, but if it’s not, then KDE and Windows had equivalent lack of clipboard history without extra tools installed.
Basically when you buy your subscription you also get perpetual access to the current X.Y.Z version + any future bugfixes (Z). So if you stop paying next year you still have access to the version from when your started your subscription.
If I subscribe for 10 years then can’t afford it any more I’m rewarded with a 10 year old version of the software? It should be the version that was current when you finished your subscription.
as soon as you pay for 12 consecutive months, you will receive this perpetual fallback license providing you with access to the exact product version for when your 12 consecutive months subscription started.
The basic software like the Intellij Community Edition is also fully open source. (And it’s not actually basic at all. It’s a great full featured IDE)
Basically you’re only paying for their support/updates and for specific language and toolkit support, which makes sense to me. They need to pay their staff somehow.
It’s not comparable to Adobe or other crappy manufacturers where you own nothing.
The problem is that all projects start small, and frankly most of them die small. Aiming for microservices architecture right away is a surefire way to get the project killed before anyone would benefit off of the microservices.
The other angle is the majority of Devs are just… Not good…
A good Dev in the situation you mention will design the solution needed now not the one you hope for later.
I’m saying this as someone who has been mired in scope creep and over engineering solutions many times in my life because “what if 5000 people need to use it at once?!”
In most cases all you need is a database, a single thread and a simple API. Build it and then as the problems come grow with them. Try to take into account issues of scale but realize you can’t and shouldn’t solve every scenario because there are too many variables which may never exist.
A good Dev in the situation you mention will design the solution needed now not the one you hope for later.
Maintainability is one of the most important if not the most important goal when programming. If a dev only designs a solution that fits for exactly the current situation but doesn’t allow any changes, it’s not a good dev.
But yeah, if you start small, a solution that’s made for that is preferable. You can still refactor things when you get magnitudes larger and have the budget.
The tricky thing about software development is this balance: you don’t want to hobble your system by designing only for today, because that could waste a whole lot of time later when needs change, but you also mustn’t paralyze the project by designing for all possible tomorrows. Finding a middle path is the art, and the only proof that you got it somewhat right is that things get done with relatively few crises.
Microservice from the start may be a lot of overhead, but it should at least be made with that scalability in mind. In practice to me, that just means simple things like make sure you can configure it via environment vars, run it out of docker compose or something because you need to be able install it on all your dev systems and your prod server. That basic setup will let you scale if/when you need to, and doesn’t add anything extra when planned from the start.
Allocating infrastructure on a cloud service with auto scaling is the hard part imo. But making the app support the environment from the start isn’t as hard.
Often a simple solution is the most maintainable solution. In my experience, the code that’s most difficult to maintain are often made by devs who tried to plan ahead. The code turns over engineered to allow for stuff that never materialized.
You evidently haven’t met my colleagues. There are always people who go for the quickest hack despite the trouble it stores up for later, and they’re usually encouraged by management.
I always lump microservices architecture as premature optimization, one that should be used when you’re maxed out of resources or everything is too spaghetti.
I love the idea. And I even pitched it for a specific project. But I had to eat humble pie when the devops nerds threw more servers at the problem and it worked better than I expected.
Sounds like that thing was already designed to be horizontally scalable. Was your error related to not realizing that? Or what was the problem being solved by microservices?
Microarchitecture needs to be broken up into components. Those components need to send messages to each other. Components sending messages to each other is arguably the core of what object oriented design was trying to do all along. If your devs were bad at classifying components in an object oriented design, then they’ll probably be bad at it in a microarchitecture, too. Worse, the actual system is now likely spread amongst many different version control repositories, and teams stake out ownership of their repositories. Now you get more blockers spread amongst several teams.
Where the network layer comes into play is to replace something that used to be running in a single CPU core, or sometimes different cores on the same motherboard. Unless you can exploit parallelization for your use case, the kind where you have more threads than the number of CPU threads a single motherboard can handle (which can be several hundred on current systems), this will always be slower.
Being an older system admin this is how we worked. Would generally have an A and B side and maybe C on our stacks. Most of the time what I supported would be A and B clusters in two data centers and then do either 100% on our primary site or do a mix of traffic between our two sites
Most software developers have no concept of real world limitations and issues like tolerances, failure, probability, latency, hysteresis, ramp-up etc. because they’re not engineers.
Normally they’d be expected to at least account for software-specific aspects like ACID or CAP or some vague awareness of the fact that when you’re dealing with multiple systems the data may not always arrive as you expect it, when you expect it. But even that is a crapshoot.
It is not machine learning and LLM that pisses off Lemmy users. Its the application of said technologies. I don’t give a flying fuck what people are doing with ChatGPT, its novel. I want a generative AI that can help me code.
I don’t agree. Every time I have tried to point out that GitHub copilot is a helpful tool, the trolls come out of the woodwork to tell me I’m wrong and a shitty developer
I have luck with it daily. I wouldn’t want to return to writing code without ever having little shortcuts builtin to my workflow throughout every day. It certainly saves me time and I have some other teammates who agree. Some luddites on the team also, but I don’t let their fear bog me down. I think everyone who is strictly against copilot actually has failed to ever try it
Microservices can be useful, but yeah working in a codebase where every little function ends up having to make a CAP Theorem trade-off is exhausting, and creates sooo many weird UX situations.
I’m sure tooling will mature over time to ease the pain of representing in-flight, rolling-back, undone, etc. states across an entire system, but right now it feels like doing reactive programming without observables.
And also just… not everything needs to scale like whoa. And they can scale in different ways: queue up-front, data replication afterwards, syncing ledgers of CRDTs… Scaling in-flight operations is often the worst option. But it feels familiar, so it’s often the default choice.
Do you feel gitops tools like fleet/argocd/flux and kubernetes don’t cover most of the deployment/rollback and system state management problems so far?
I’m talking about user interactions, not deployments.
In a monolith with a transactional data store, you can have a nice and clean atomic state transition from one complete, valid state to the next in a single request/response.
With a distributed system, you’ll often have scenarios where the component which receives the initial request can’t guarantee the final state of the system by the time it needs to produce a response.
If it did, it would spend most of its effort orchestrating other components. That would couple them together and be no more useful than a monolith, just with new and exciting failure modes. So really the best it can do is tell the client “Here’s a token you can use to check back on the state of this operation later”.
And because data is often partitioned between different services, you can end up having partially-applied state changes. This leaves the data in an otherwise-invalid state, which must be accounted for – simply because of an implementation detail, not because it’s semantically meaningful to the client.
In operations that have irreversible or non-idempotent external side-effects, this can be especially difficult to manage. You may want to allow the client to resume from immediately before or after the side-effect if there is a failure later on. Or you may want to schedule the side-effect, from the perspective of an earlier component in the chain, so that it happens even if a middle component fails (like the equivalent of a catch or finally block).
If you try to cut corners by representing these things as special cases where the later components send data back to earlier ones, you end up introducing cycles in the data flow of your microservices. And then you’re in for a world of hurt. It’s better if you can represent it as a finite state machine, from the perspective of some coordinator component that’s not part of the data flow itself. But that’s a ton of work.
It complicates every service that deals with it, and it gets really messy to just manage the data stores to track the state. And if you have queues and batching and throttling and everything else, along with granular permissions… Things can break. And they can break in really horrible ways, like infinitely sending the same data to an external service because the components keep tossing an event back to each other.
There are general patterns – like sagas, distributed transactions, and event-sourcing – which can… kind of ease this problem. But they’re fundamentally limited by the CAP Theorem. And there isn’t a universally-accepted clean way to implement them, so you’re pretty much doing it from scratch each time.
Don’t get me wrong. Sometimes “Here’s a token to check back later” and modeling interactions as a finite state machine rather than an all-or-nothing is the right call. Some interactions should work that way. But you should build them that way on purpose, not to work around the downsides of a cool buzzword you decided to play around with.
I struggle to think of any code with real-world applications that doesn’t have to make CAP tradeoffs. The reason that often doesn’t seem to be the case is willful ignorance.
The only way you can have ACID in a monolith is if the data store is incorporated into the RAM when the code runs and the code is not interacting with any exterior system.
Typically the data store is external though and yes you can have atomic states in the data store but that doesn’t translate to your code. That’s CAP right there, between your code and your data running on two distinct systems.
I mean I made be a novice on this but multi-state service in general sounds like a bad time. Isn’t the accepted best practice for a micro service program stateless operations and one state at most per service?
I mean its true for anything beyond a single threaded monolith right? Otherwise you just get apps that prentend to be asynchronous waiting on locks so they act totally synchronousaly.
One of our customers recently had tasked us with building a microservices thing. And I already thought that was kind of bullshit, because they had only vague plans for actually scaling it, but you know, let’s just start the project, figure out what the requirements really are and then recommend a more fitting architecture.
Well, that was 3 months ago. We were working on it with 2 people. Then at the end of last month, they suddenly asked us to “pause” work, because their budget situation was dire (I assume, they had to re-allocate budget to other things).
And like, fair enough, they’re free to waste their money as they want. But just why would you start a microservice project, if you can’t even secure funding for it for more than a few months?
In this case, the colleague who had talked to the customers told me, they wanted microservices, because they’d have different target systems which would need differing behavior in places.
So, I’m guessing, what they really needed is:
a configuration file,
maybe a plugin mechanism, and
a software engineer to look at it and tell them the behavior is actually quite similar.
programmer_humor
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.