motorest

17 ms·

241.
by motorest 1y ago
> My experience with Next.js are that its rough edges are a feature, not a bug. Everything is geared towards you giving up and just using Vercel's hosting That is my opinion as well. Things like SSR are forced onto users with a very
242.
by motorest 1y ago
> I 100% agree. I've ran into the same issues, and I would never use Next.js for anything, and I will encourage every team at work to use something else. Things will get far worse before they get better. Right now, online courses
243.
by motorest 1y ago
> I feel like these functional GUI renderers are all trying to make JS something it is simply not. I wholeheartedly agree. I liked React's support for function components and hooks are quite a treat, but still I think class componen
244.
by motorest 1y ago
> Which dimensions do you see Google lagging on? They seem broadly comparable on the usual leaderboard ( https://lmarena.ai/leaderboard ) and anecdotally I can't tell the difference in quality. Gemini holds indeed the
245.
by motorest 1y ago
> This is not really true. Google has all the compute but in many dimensions they lag behind GPT-5 class (catching up, but it has not been a given). I don't know what you are talking about. I use Gemini on a daily basis and I honest
246.
by motorest 1y ago
> Are you arguing anthropic has more compute than Amazon? I wouldn't be surprised if the likes of Anthropic wasn't paying AWS for its compute. As the saying goes, the ones who got rich from the gold rush were the ones selling s
247.
by motorest 1y ago
> Thanks for switching sides to oppose yourself, I guess? I'm baffled by your comment. Are you sure you read what I wrote?
248.
by motorest 1y ago
> It isn't only about template code. zapcc speeds up compilation when there's no cache. Someone else in this thread already pasted benchmarks. The observation was, and I quote: > Zapcc focuses on super fast compile times al
249.
by motorest 1y ago
> Here are some performance numbers: https://www.phoronix.com/news/Zapcc-Quick-Benchmarks If you look at the benchmarks you just quoted, you see cache-based compilations outperforming zapcc in quite a few tests. I w
250.
by motorest 1y ago
> ccache works at a translation unit level which means it isn't any better than just make-style incremental rebuilds when you aren't throwing away the build directory You used many words just so say "ccache is a build cach
251.
by motorest 1y ago
> Do you actually think dead simple failover is comparable to elastic kubernetes whatever? References to "elastic Kubernetes whatever" is a red herring. You can have a dead simple load balancer spreading traffic across multiple
252.
by motorest 1y ago
> It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instanti
253.
by motorest 1y ago
> 'm not asking the standards committees to develop them for free. They were already developed! That's great to hear. It sounds like you have everything set to put together a proposal. Do you have any timeline in mind to presen
254.
by motorest 1y ago
> Both zapcc and Fil-C could benefit from the involvement of the standards committee. I think there is a hefty deal of ignorance in your comment. A standardization process is not pull-based, it's push-based. If you feel you have a n
255.
by motorest 1y ago
> The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: http
256.
by motorest 1y ago
> Of course it was completely ignored. Did you expect the standards committee to enforce caching in compilers? That's just not its job. There are also quite a few compiler cache systems around. For example, anyone can onboard tools
257.
by motorest 1y ago
> don't you think it's highly unlikely that someone will stumble over the power cable in a hosted datacenter like hetzner? You're not getting the point. The point is that if you use a single node to host your whole web app
258.
by motorest 1y ago
> My experience after 20 years in the hosting industry is that customers in general have more downtime due to self-inflicted over-engineered replication, or split brain errors than actual hardware failures. I think you misread OP. "
259.
by motorest 1y ago
> In a company there are other employees who have your success as part of their job function. Yes, and they enforce basic relase processes to ensure you don't break releases by skipping QA processes or introducing untested and unver
260.
by motorest 1y ago
> Which also, at times, means appeasing people even when you are confident that they are wrong because you need their cooperation in the future. Being unwilling to follow basic QA processes in preparation of a release candidate, and then
261.
by motorest 1y ago
> Linus has broken the build more recently than I have. Even taking your claims at face value (which from this thread alone is a heck of a leap) I'm baffled by the way you believe this holds any relevance. I mean, the kernel project
262.
by motorest 1y ago
> No, I'm sorry but you're simply wrong. It sounds like you have a hard time coping with reality. https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur... I repeat: it sounds an awful lot like you a
263.
by motorest 1y ago
> You might want to read the full story on that one. I read the full story. Everyone else can do the same. Somehow it seems you opt to skip it and prefer to be deeply invested in creating an alternative reality.
264.
by motorest 1y ago
> Too solve a bug with the filesystem that people in the wild were hitting. So you acknowledge that this last episode involved trying to push new features into a RC. As it was made abundantly clear, not only is the point of RC branches t
265.
by motorest 1y ago
> This was a bug fix. I'm not sure exactly what you are talking about, and I'm not sure you do either. The discussion that preceded bcachefs to be dropped from the Linux kernel mainline involved an attempt to sneak a new featur
266.
by motorest 1y ago
> We were never able to get any sane and consistent policy on bugfixes, and I don't have high hopes that anyone else will have better luck. This reads an awful lot like blatant gaslighting. It's quite public that you were kicke
267.
by motorest 1y ago
> It's a bugfix, and bugfixes are allowed at and time (...) I'm afraid you sound like you're trying to gaslight everyone in the thread. https://news.itsfoss.com/linux-kernel-bcachefs-drop/
268.
by motorest 1y ago
> Regardless of differing points of view on the situation, I think everyone can agree that bcachefs being actively updated on Linus tree is a good thing, right? I think bcachefs is not the problem. The problem seems to be the sole mainta
269.
by motorest 1y ago
> All the discussions seem to show the same issue: You disagree with policies held by people higher up than you, and you struggle with respecting their decisions and moving on. I think it's less subtle than that. The straw that brok
270.
by motorest 1y ago
> When rules and authority start to take precedence over making sure things work, (...) Didn't Linus lambast you for "lack of testing and collaboration before submitting patches", to the point the patches you were trying t

More ›