Earlier quoted context omitted.
> My favorite example here is Android refusing to support stateful DHCPv6; it's clear that it's being pushed by purist networking geeks inside Google. If you read the huge bug on it, Google's counter argument is stateful dhcpv6 significantly complicates tethering to the point of needing an ipv6 nat. That's a very practical position to take, hardly "purist network objectionists"
So what? The Linux kernel already supports NAT66. Android uses the Linux kernel. I use Tailscale and when I use an IPv6-only node as the exit node, NAT66 is being used. Use `ip6tables -t nat -vnL` to check. You can also grep for `v6nat = true` in Tailscale logs. It's those purists at Google that decide that NAT66 is evil and should not be used and therefore they have chosen not to support stateful DHCPv6.
HTTP/3 is everywhere but nowhere
461–470 of 504 posts
Re: HTTP/3 is everywhere but nowhere
#462Earlier quoted context omitted.
Google operates at such a scale that tiny increases of performances allows them to support a team of engineers and saves money on the bottom line. For example, Google hires 10 engineers, they deploy HTTP/3, it saves 0.5% cpu usage, Google saves a million dollars and covers the salary of the said 10 engineers. For the vast majority of society, the savings don't matter. Perhaps even deploying it is a net-negative with…
It absolutely matters. Machines are orders of magnitude faster than they were 20 years ago; most software isn't doing much more than software did 20 years ago. And no, collaborative editing isn't be-all, end-all, nor does it explain where all that performance is lost. Many optimizations have bad ROI because users' lives are an externality for the industry. It's Good and Professional to save some people-weeks in devel…
This isn't exactly true, but some of the potential reasons are pretty bad. Software turning into an ad platform or otherwise spying on users has made numerous corporations wealthier than the gods at the expense of the user is probably one of the most common ones.
Re: HTTP/3 is everywhere but nowhere
#463Earlier quoted context omitted.
"All other languages" is a stretch IMO. Any language that has proper macros (e.g. Rust, Clojure) can do something LINQ-like as well as C#.
Can you post some examples? Having been working in TS with Prisma for a bit, what stands out is how a Prisma query is effectively trying to express an expression tree in structural form An example on TS with Prisma: const loadedAda2 = await tx.runner.findFirst({ where: { email: 'ada@example.org' }, include: { races: { where: { AND: [ { position: { lte: 10 } }, { time: { lte: 120 } }, { race: { name: { contains: 'New'…
Proper macros operate on AST, which it to say, it is exactly like the Expression stuff in C#, except it can represent the entirety of the language instead of some subset of it (C# doesn't even fully support the entirety of System.Linq.Expressions - e.g. if you want LoopExpression, you have to spell the tree out explicitly itself).
Re: HTTP/3 is everywhere but nowhere
#464Earlier quoted context omitted.
> obviously system.windows.forms could easily be implemented elsewhere It can, but not easily . As OP has said, it is a wrapper around Win32, and not an opaque one - it literally has stuff like e.g. the Message struct with members like HWnd and LParam. Mono did try at one point, but they kept hitting edge cases where this kind of stuff would break things. Eventually they gave up and just wrapped Wine. So, yes, if you…
well maybe because there exists countless gui applications that uses it, and furthermore, if you say its crossplatform, you cant say that with a straight face unless you also support gui? fact of the matter is, microsoft was perfectly happy to preach their .net shit as cross platform to try extend into non-windows usage, except for gui stuff, as thats "for windows"
Note that C++, Rust, Go all don't have any kind of standard GUI support out of the box at all.
Re: HTTP/3 is everywhere but nowhere
#465Earlier quoted context omitted.
You forgot to mention that Miguel de Icaza was probably the single biggest .NET fanboy for literally decades before throwing in the towel. The fact that a person like this ended up being alienated tells volumes. I should also add that the general public only saw the tip of the iceberg in this entire episode. Miguel spent a lot of time and effort internally trying to right the .NET ship, gradually escalating through m…
I don’t doubt this but the criticism has to be rooted in facts and the current state of affairs, and you have to consider conflict of interest. It’s not too different to what you can read here. No one ever talks about whether C# offers good cohesive experience when solving a specific task, or what are the pros and cons of its build system, or how a typical .NET team looks like in a particular region. No. Instead, the…
Speaking for myself, I happen to like .NET from the technical perspective. While both the language and the stdlib have a lot of cruft from days of yore, it can mostly be ignored, and that aside it's a fast runtime with a decently expressive type system giving one considerable flexibility to pick the right tool to model different domains. It also has great tooling around it. But this all is separate from the question of how open .NET really is, and its long-term prospects in that department.
Re: HTTP/3 is everywhere but nowhere
#466Earlier quoted context omitted.
https://learn.microsoft.com/en-us/dotnet/api/system.diagnost... Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example. Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!
I'm not sure why you are reading the docs sideways but just in case - C# has method overloading. Process API, while dated, simply offers multiple overloads suitable for different scenarios. Launching a new process can be as easy as `Process.Start(path, args)`. Although if you are doing this, I can recommend using CliWrap package instead which provides nicer UX. Anything is possible the second you stop looking for a s…
Yeah I do have a life. I advice you to get one as well.
> Launching a new process can be as easy as `Process.Start(path, args);`.
-_-' Same exact problem. Letting every single process do their own escaping of the arguments. A proper portable API would have an array of strings for the arguments, to map execve(). That's how on windows every program does its own escaping and there's lots of programs doing it differently than others, but not how it works on posix.
Thanks for confirming you don't even comprehend the issue here. Crying "strawman!" won't help.
> If it's a CLI or a GUI application, I'd distribute it as either a native binary or as the recipe the user will be easily able to build with the .NET SDK (which is a standard approach - you'd need Rustc and Cargo in the same way).
You can't do any GUI in .NET outside of windows and you know it fully well.
The difference with cargo or go or pip is that all of these are found in every linux distribution, while .net is in none. Please go ahead and misunderstand this sentence on purpose like you've been doing so far.
> in all the distributions that matter it is `sudo {package manager} install dotnet9` away :)
I guess ubuntu, debian, red hat do not matter? What's left? neonsunsetimaginarylinux?
Re: HTTP/3 is everywhere but nowhere
#467Earlier quoted context omitted.
Plenty of mobile users use wifi at home/work. Telling them to disable their ipv4-only wifi just to play your game is going to be a non-starter, especially when the cost of ipv4 address adds negligible cost to infrastructure. Is your CTO really going to massively increase user friction ("turn of your wifi to play!") just so try to save a few cents (comparatively speaking) on infra?
It could be in a country where people don't have home wifi.
Re: HTTP/3 is everywhere but nowhere
#468Earlier quoted context omitted.
That comes after adding an untrusted 3rd party repository no? Why are you omitting that part? Which means that nothing written in .net will enter the real repository until that changes.
Because in the relevant distros it is included in the first-party feeds. Only Debian acts like a special snowflake making it needlessly complex for everyone (including Rust). I believe there is an ongoing work to modify .NET's full source build (i.e. https://github.com/dotnet/source-build ) to satisfy Debian's admission requirements, but really it's a problem inflicted by Debian on themselves, not the other way aroun…
Re: HTTP/3 is everywhere but nowhere
#469Earlier quoted context omitted.
It's not Windows only but it is Windows-first. Every few years I take a look but it still doesn't feel like a serious ecosystem for Linux development (in the same way that e.g. Perl might have a Windows release, but it doesn't feel really first-class). I can't think of a single .NET/C# program that people would typically run on Linux to even have the runtime installed, so no wonder people don't bother investigating t…
Definitely not Windows-first. Last startup we built our entire backend in .NET and C#. Every dev ended up using MacBooks. We shipped to AWS t4g Arm64 Linux targets. This mis-perception is so irrational and not based on any facts.
You're seeming like the node developers trying to push js everywhere because it's all they know. It's not a very rational approach I think.