HN user

Droobfest

294 karma
Posts0
Comments75
View on HN
No posts found.

I’m sorry but no. Maybe it’s my ignorance of TM’s, but O(log n) doesn’t read all input by definition. It doesn’t follow that it is therefore _independent_ of the input size.

What makes a/your TM special that this is the case?

I don’t mean to take too much of your time though, maybe I’m too dumb for this.

Edit: I can sort of see how O(log n) is impossible or at least O(n) in a TM, but to reduce it to O(1) makes no sense to me

There is nothing wrong with apt and dpkg. It’s just that Ubuntu infected apt with their poison by making ‘apt install firefox’ install a snap package and they’re poised to do it with more packages (maybe they already have).

I personally can’t think of anything software related that Ubuntu provides over Debian for normal desktop users. Only the Ubuntu 6-month release schedule can be a bit nicer.

It's a matter of risk that I'm paying for to avoid, not absolute quality. I would not wager my life on a random doctor in Africa even while 90% of doctors there might be more skilled than in London. I'm paying to eliminate the risk of encountering the worst 10%. In that light, yes I would personally expect the doctors in London to be able to avoid the worst outcomes better on average. Whether that's warranted is another discussion.

This goes for loads of stuff. I would wager a $30 meal to be fresher than a $5 meal on average. I'm not saying there aren't any $5 meals that are fresher than some $30 meals, but just that the $30 has a lot lower chance to make me sick.

This is what api's are for. A telemetry service asks each service for the specific data, combines them and outputs the combined metrics. This doesn't really break a barrier, but it does increase overhead.

Even though I didn't expect much I'm still disappointed after using it a little. It's very rough around the edges.

When I run 'winget list' It says I have Firefox 88.0 installed and there's an update for 88.0.1. But then I run 'winget upgrade Mozilla.Firefox' and it says 'No applicable update found'. Very similar stuff happens even for very popular Microsoft apps like VS2019 and VSCode, there it runs the installer but either doesn't update at all (VS2019) or winget thinks it's perpetually out of date (VSCode). For most other packages it cannot even link the listed application-id to the corresponding winget package, even if it definitely exists.

I understand it's all very variable and nonstandard in the Windows ecosystem, but I think it should be possible to get the versioning mostly right and build a much better database of application-ids and corresponding package names.

Well I'll admit there is still a balance to it.

I'll just say that the emphasis should be on clean branches and PR's much more than clean individual commits. And on good code much more than clean git branches.

If there's too much ceremony around branches and pull requests I tend to avoid small fixes because it's just much work and that definitely doesn't improve the quality of the code.

Yea... no.

An overly clean git history for me is a sign of too much perfectionism and greatly reduced productivity.

When I code I usually have a general idea of the stuff I want to include in my branch, but then I stumble upon bugs or code couplings which I need to fix for my feature to work. And then I include the fix into my feature branch, because it's just tedious to switch all the time and create 5 interdependent branches that need to be merged together anyway. Also as long as the feature branch itself is fairly clean then I don't give a rats ass about atomic commits.

And commits having to pass tests is just ludicrous. That's what the tests are for, so you can fix it before merging the branch. Don't go crazy on the commit level..

It depends a bit on the project, and how public it is. But in the end your git history never provides any benefit to customers and doesn't make your code better by itself. I hardly ever rewrite or rebase commits unless there's a good reason for it.

I generally agree with this, but making sure your error messages are correct is even more important than terseness. The last example of the article is a perfect illustration of this:

  $ cat invalid
  cat: invalid: invalid path
An invalid path or a file not found are not the same thing! The real danger is that being too terse and unclear is worse than unnecessary verbosity.

This eventually becomes a microservices vs monolith discussion though.

Implementing both the message queue and the bank core integration service within 1 service makes for less communication/network overhead and is easier to debug, which is definitely valuable.

Seperating them out means you can use off the shelf products for the message queue and is easier to scale, which can also be valuable.