Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kohlerm
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
23 ms
·
121.
▲
by
kohlerm
5y ago
it's great project. No idea why some people do not want to eq their headphones at least a little bit. It can make a huge difference. Also frequency response is IMHO at least partially a matter of taste.
122.
▲
by
kohlerm
5y ago
Another approach is to use a main stream distribution in combination with the nix package manager. You can then always fall back to the distributions native packages.
123.
▲
by
kohlerm
5y ago
Yes
124.
▲
by
kohlerm
5y ago
Click bait. Just because there are preppers in Germany that doesn't mean it is not a stable country.
125.
▲
by
kohlerm
5y ago
With regards to Software, SAP is still german and runs the worlds biggest companies
126.
▲
by
kohlerm
5y ago
"Funny" fact it seems like the FDP is the party of "no opinion", e.g they are neutral to a lot of questions.
127.
▲
by
kohlerm
5y ago
In this context I can recommend the book https://www.goodreads.com/book/show/25666050-algorithms-to-l... . Basing decisions solely on regret minimization is certainly not a good idea. You need to spend some time
128.
▲
by
kohlerm
5y ago
My second Linux installation came with Xwindows. IIRC that were like 4 or 5 floppies
129.
▲
by
kohlerm
5y ago
hmm not sure I can follow the logic. Germany does have quite a lot of wind power doesn't it? Also AFAIK prices in Germany went up because of higher demand for Gas. And then somehow it is expected, as soon as there is a big enough cris
130.
▲
Keyboard Input Latency Compared: Wireless BLE ZMK, QMK, and Corsair
(youtube.com)
3 points
by
kohlerm
5y ago
|
2 comments
131.
▲
by
kohlerm
5y ago
I assume your Ergodox is running QMK, which depending on some configuration values had a relatively slow debouncing mechanism. I think times were around 20ms. Checking https://www.youtube.com/watch?v=jWL4nU-vtWs which comp
132.
▲
by
kohlerm
5y ago
This is in my experience the most common performance antipattern. What makes it even worse is the fact that people quite often do this on the name of performance. Which rarely is a good idea.
133.
▲
by
kohlerm
5y ago
I am hoping this was meant to be a joke. If not fire him ;-)
134.
▲
by
kohlerm
5y ago
Very nice, when I read "double linked list" I immediately thought "what about a btree like structure?" I guess Martins idea to replace the IDs comes from the "vector clock" idea for concurrent updates
135.
▲
by
kohlerm
5y ago
The Gizmodo review is odd. Comparing this to an M1 based Apple Laptop, with regards to battery performance? You could do that for every Intel/AMD laptop and they all will kind of suck. But if you do not want Apple or you need Intel
136.
▲
by
kohlerm
5y ago
I guess that depends on your definition of "Edge". There are quite few a "hybrid" (cloud plus on-prem) use cases where running K8s on-prem can be a good option. If you check https://azure.microsoft.com/
137.
▲
by
kohlerm
5y ago
Not sure I understand what you say. But a repo for a library that is used only internally in an application does not need to be published to "customers"(real external customers or internal customers such as another microservice).
138.
▲
by
kohlerm
5y ago
That is just a best practice for published interfaces (allowed to be used outside of your repositories). E.G. using a different build, main example being APIs available for customers) Not all interfaces need (really "must not")
139.
▲
by
kohlerm
5y ago
Seems like a common misconception to me that people seem to believe that you can never change an interface. You actually can as long as it is not published to be used outside of your repositories.
140.
▲
by
kohlerm
5y ago
I am saying large-scale refactoring can and should (in same cases) happen (and are doable). The author claims you should always do it in steps. I disagree with this opinion. If the refactoring is automatic, why would I do it in steps?
141.
▲
by
kohlerm
5y ago
It is not the monorepo which forces trunkbased development it is the fact that you use one build for the monorepo. E.g. you can do trunk based development with multiple repos by forcing everyone to use a common build. You could also use a m
142.
▲
by
kohlerm
5y ago
You can do automatic bisecting https://git-scm.com/docs/git-bisect which you cannot easily do with multiple repos
143.
▲
by
kohlerm
5y ago
You do not need Monorepos for trunk based development. In principle you "only" need a common build system. E.g. You can just force the consumption of head via the build system. I think the rollback is still a factor. E.g. in a Mon
144.
▲
by
kohlerm
5y ago
I do not really agree with the conclusion. Google does large scale automatic refactorings. Those clearly benefit from atomic commits, because it is easy to roll them back in that case. As other have mentioned in smaller projects you might w
145.
▲
by
kohlerm
5y ago
WSL2 is using a real Linux kernel with almost no limitations. But it doesn't pass through the GPU. Therefore graphical applications are relatively slow.
146.
▲
by
kohlerm
5y ago
I forgot. ATM I use Ubuntu with the nix package manager, not Nix OS. The reason being that in case a package is not available on Nix, or is not working out if the box. I found for example that Visual Studio remote support does not work out
147.
▲
by
kohlerm
5y ago
Not that weird of a setup. A few years ago I was responsible for dev environments for >500 developers. I wasn't aware of Nix at that point in time, so we provided prebuilt Linux VMs for local and remote use,which we would update wit
148.
▲
by
kohlerm
5y ago
Yes and I think it's really generous of the LC0 to "donate" that data. On the other side LC0 uses SF during the training process since a while.
149.
▲
by
kohlerm
5y ago
A solution would need to be fast an incremental. Also we have got much faster bundlers with tree-shaking support recently (for example esbuild and parcel adopting swc), fast incremental correct builds seems to be still not completely there.
150.
▲
by
kohlerm
5y ago
I agree being able to support distributed caching of results is one of the major benefits.
More ›