pull down to refresh
0 sats \ 0 replies \ @02c42fc294 25 Jun \ parent \ on: Are software engineers more likely to be socialist? AskSN
But this is hardly specific to software engineers, as people embedded in certain contexts, it think we all tend to bring our work and context to the political table. Noatter which orientation.
I think there is some truth to this. Software engineers as I know them are rather well paid, but also very aware of the privileges that come with it, so the challenge of designing a system that elevates everyone to the same level of wellbeing is definitely there (even if sometimes only as a mind game). Being an engineering discipline we also rarely deal in absolutes, rather we are aware that tradeoffs are necessary to make progress in the real world. And finally, as several people have pointed out there is also some hubris involved, since rule setting and world building is much of a software engineers daily work (but with the realism that every set of rules can be exploited, hence we don't tend to strive for perfection, rather a good enough).
Same here, I used to use a blame diff, and use the commit whose commit hash is just above or below the modified lines. Absorb just does it automatically.
Still, it's different if one custodian gets popped, and people who (maybe unknowingly) accepted the custodian risk, or if the entire security basis of the entire Bitcoin ecosystem is broken. Coinbase isn't high impact, it's not the entire ecosystem.
"... because it would affect their own encryption...", another fallacy: appeal to rationality. He's assuming that there aren't powerful entities that either don't grasp or just don't care about the fallout.
Well, it is also a very human thing to obsess around these catastrophic events. See the fear of airplane crashes vs car crashes, one gets all the attention while the other is the actual killer.
That's what we call a low-probability / high impact event: quantum computers are unlikely to become powerful enough to steal coins in the next couple of years, but if they do, almost all coins are at risk. Comparing that to a high probability / low impact (comparatively) Event like an individual users coins being stolen makes little sense. This is called fallacy of relative privation, and relies on the inability to correctly gauge the impact of low probability events.
Well, what did we expect when we deregulated everything? Governments and regulation are there to reign in the excesses of free markets (they literally are the only thing preventing monopolies long term), so if we deregulate we allow abusive and extractive behavior. And abusers get used to it and block any move in the other direction
Eventually the pendulum will swing back.
Too bad it had to be a memecoin (is it still a memecoin when er get utility from it's use?), but it's about time we disintermediated the cartel of scientific publishers. I hope this makes a dent into the Springers margin, ideally we'd set it up to compensate authors and reviewers for their hard work, rather than the legacy paper transport system for information.
Cool, doxxing developer financials as an incredibly inefficient method to control spam, that's what Bitcoin is all about /s
Oh, and guess why the fees went up after the block mined by ocean: because it was not full, we wasted available capacity, kept the mempool full, and disoriented fee estimators...
So the transactions were not mined when there was spare capacity, the block was not fully utilized and the transactions linger in memory because other miners deemed them too low fee? Nothing here singles out ocean as a positive: they wasted block capacity, the lingering transaction will likely eventually still confirm, and in the meantime they float in the mempool and waste cycles of other miners trying to build a block template.
Ocean behaves just like any normal miner, foregoing transactions it doesn't seem valuable. It's only their cost function is changed, which in a distributed system may cause unexpected effects (heterogenous policies as an attack vector is quite common).