Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kakwa_
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
4 ms
·
31.
▲
by
kakwa_
5mo ago
After having way too strong opinions about this, and even if Go is my go to language, I've stopped caring for this kind of statements. In the end, the language doesn't really matter and extremely rarely is the bottleneck. Python,
32.
▲
by
kakwa_
5mo ago
Well, it depends. Managing and coordinating a bloated organization always has a cost and an overhead, from communication issues to technical inefficiencies. And I also doubt the frontend/backend divide is so clear. I would bet quite a
33.
▲
by
kakwa_
5mo ago
It's not always the case, for example Japan has very low immigration. And there is also the demographic disparity at play here. The US is attracting migrants mainly from Latin America, that's a population basin of 650M people, rou
34.
▲
by
kakwa_
5mo ago
Are these principles really about sustainability? It seems to be far more geared toward promoting some sort of misplaced post-collapse resiliency. In other words: solving some hypothetical issues on the other side of a catastrophe for a wor
35.
▲
by
kakwa_
5mo ago
Pretty standard in highly regulated fields like aerospace, finance/banking or industry. Sometimes for good reasons, like thorough validation need or operational constraints like spaced-out maintenance windows. Sometimes for bad reasons
36.
▲
by
kakwa_
5mo ago
For the home page, I would recommend the "UnTrap for Youtube" browser extension.
37.
▲
by
kakwa_
5mo ago
Your toaster is well... a toaster. And even something as simple toaster might need some customer support. These things do fail quite often, sometimes dangerously. Increase complexity even a little; or worse, deal with a service (phone, inte
38.
▲
by
kakwa_
5mo ago
I feel this report is missing something when it puts all OSS developers into the same bucket, and somewhat fails to define what an OSS developer actually is. There is tons of variability depending on many factors like the project complexity
39.
▲
by
kakwa_
5mo ago
Honest question, is leetcode tests an actual failure from the recruiting company perspective? Sure, it means that from time to time you will reject people like the Homebrew creator. And it also means the recruiting process now sucks for the
40.
▲
by
kakwa_
5mo ago
On the other hand, most pieces of software in this world are kind of mediocre code written by unmotivated employees within tight timelines. In such context, I think Go might be a better or at least, more realistic, compromise in most cases.
41.
▲
by
kakwa_
5mo ago
I think the gain sits in the middle: if the giant server starts to get iffy (moderation, content, policy, technical issues), people can leave it somewhat easily and form or grow another decently sized server which will have enough reputatio
42.
▲
by
kakwa_
5mo ago
Concrete example: A few years back, our support team needed to do some network capture with tcpdump. The quick and natural way to allow that was to add a sudo rule for it, with opened arguments (I know it's a bit risky, but tcp port an
43.
▲
by
kakwa_
5mo ago
I feel like more money would not have helped that much. Maybe it would have enabled a few of the devs to work on it full time, but I doubt it would have brought more people into the project. I would indeed love the EU to step in but not in
44.
▲
by
kakwa_
5mo ago
Syncing the code is the easy and trivial part and your CI job is only solving that. And in my opinion, it's not even that necessary for most projects. The difficult part is all what's around the code: * the tickets/PR (includ
45.
▲
by
kakwa_
5mo ago
I would have been happy if all that happened like 3 years ago. Now, it's 5 years in, the Asahi effort is losing momentum. Core developers are going on to do other things, significant chunks (3922 commits) are still not merged upstream
46.
▲
by
kakwa_
5mo ago
Well, after a while, the effort of maintaining and improving M-series kernel support should be directly be done by kernel maintainers, not within a fork with periodic merges (maybe some Asahi folks should become kernel maintainers). Doing s
47.
▲
by
kakwa_
5mo ago
While I absolutely love the technical write-up from the Asahi team, and being absolutely impressed by their accomplishment, to the risk of being an overly negative contrarian, I remain a bit skeptical. I'm concerned that after all thes
48.
▲
by
kakwa_
5mo ago
> I usually find it easier to take their branch, do all of that work myself (attributing authorship to commits whenever appropriate), push it to the master branch and close the PR than puppeteering someone halfway across the globe throug
49.
▲
by
kakwa_
5mo ago
That one is murky. I would argue it falls more on a case like the Linux distributions one and the guy in South America is responsible. Google, in my opinion, can be held accountable for Android because they deeply control the ecosystem (App
50.
▲
Show HN: My Silly Sun Server
(technically.kakwalab.ovh)
3 points
by
kakwa_
5mo ago
|
0 comments
51.
▲
by
kakwa_
5mo ago
IMHO, the law tries to target the last entity which has practical control over the OS design and implementation aka the final developer/integrator. For example in the Linux world, it's the distributions. Where it gets murky is wit
52.
▲
by
kakwa_
6mo ago
More like an idea decently likely to be resold for more. Good ideas are a decent subset, but you could also have a bit of "Greater Fool Theory" compliant ideas.
53.
▲
by
kakwa_
6mo ago
While I do get why CMake is a scripted build system, I cannot help but notice that other languages don't need it. In Rust, you have Cargo.toml, in go, it's a rather simple go.mod. And even in embedded C, you have platformio which
54.
▲
by
kakwa_
8mo ago
The graphic stack in NT is done in a microkernel fashion, it runs in kernel space but doesn't (generally) crash the whole OS in case of bugs. There are a few interviews of Dave Cutler (NT's architect) around where he explains this
55.
▲
by
kakwa_
9mo ago
That's not enough by a long shot. There are already plenty of devices, from old phones to vacuum robots, where we have that or near enough. Technically, we know how we could maintain/re-flash these devices. Yet, we don't. Why
56.
▲
by
kakwa_
9mo ago
Well, not mass produced enough. Common mass produced products manufacturers have incentives to not mess-up too badly: recalls or warranties on such scales are a nightmare. With military contracts, its a paid maintenance opportunity.
57.
▲
by
kakwa_
9mo ago
Just a few bits about that. I would recommend looking into the chroot based build tools like pbuilder (.deb) and mock (.rpm). It greatly simplifies the local setup, including targeting different distributions or even architectures (<3 bi
58.
▲
by
kakwa_
10mo ago
Fragile against upgrades, tons of unmaintained plugins, admin panel UX is a mess where you struggle to find the stuff your are looking for, half backed transition to nicer UI (Blue Ocean) that has been ongoing for years, too many ways to se
59.
▲
by
kakwa_
10mo ago
Maybe I have low standards given I've never touched what gitlab or CircleCi have to offer, but compared to my past experiences with Buildbot, Jenkins and Travis, it's miles ahead of these in my opinion. Am I missing a truly better
60.
▲
by
kakwa_
10mo ago
Sometimes, I'm wondering if Mozilla did not get too much money. With an order of magnitude less money, I think they would have been more focused on improving Firefox rather than trying to diversify with projects like Firefox OS, VPN se
More ›