Hacker Newsnew | past | comments | ask | show | jobs | submit | markstock's commentslogin

People who run WSL are not normal users. The filesystem problems make Windows+WSL feel like a Trabant when you're used to a Porsche.

Yes well I felt the same way with how slow Docker file systems were on Mac but I think that's fixed now.

Not really, I only care about WSL for containers, zero filesystem problems.

Because Windows is the operating system of Not Getting Fired. Fear is a stronger motivator than creativity or productivity.

Nah, some of us gave up on The Year of Desktop Linux, especially on laptops, and decided to make use of desktop VMs instead.

Believe it or not, there's plenty of people that specifically choose windows, not just out of fear of getting fired or inertia. The idea that all devs use a mac and that windows is garbage for any kind of development is purely a silicon valley bubble thing.

And there's still a big niche that Windows is your only choice since the move to Apple silicon. If you need both a dGPU and access to commercial software, its literally your only choice. Game dev especially comes to mind if you're jumping between maya, after effects, etc. Windows is also huge in finance.


Windows _is_ garbage for a lot of modern development (except thise targeting Win32). But that does not matter to the ICT department tasked with controlling and securing all endpoints, preferring a single, very well known and controllable OS over freedom and performance.

At least it isn't Wayland, or having to mix and match configurations until hardware video decoding on Chrome finally works.

Wayland is a protocol. Not a program.

The top compositors right now for desktop are KDE Plasma, Hyprland, Gnome/Mutter and all of them implement the Wayland protocol independently.

For game wrappers Valve makes Gamescope (https://github.com/ValveSoftware/gamescope) which is also a Wayland compositor.

When you run a game through a wrapper like GameScope it will draw to the Wayland Server that GameScope is running and then that subsequently writes to the parent display server (which can actually be X or Wayland).

Anyway it's a far superior and more secure protocol than whatever Windows is doing and you should for sure have ChatGPT explain it to you.


No need, I am fine running Linux distro headless for containers, or having Android and WebOS userspace instead on my other devices.

Gemini told me it was a good decision.


You do know that one is literally the worst one right? It's like you walked in and went "I'm using Netscape"

Well whatever you'll find out.


Nah the worst one is the Nazi Grok.

On the other side, I am a lifelong Linux user, and even with advanced LLMs, trying to get Microsoft Windows to behave sanely takes hours every month for years on end (thanks, day job). Things Linux figured out in 2003 are still magic or completely undoable on Windows.

Not my experience. I installed the IoT version of Windows 11 and have changed exactly one setting (put the start menu back on the left where it rightfully belongs). Nothing else has required any changes at all to get sanity, which is more than you can say for Mac (which requires half a dozen extra apps to make it same - SteerMouse, Karabina, Spectacle, etc.), or Linux, where the UI is mostly sane - if you're using KDE anyway - but you're beset by bugs and jank.

And don't say "it works for me". We know some people get very lucky with Linux and stuff just works. In my experience the typical experience is that stuff works much better on Windows than Linux.

E.g. something Windows figured out in 2000 - what happens when your system is low on ram or overloaded? Simple! Press ctrl-alt-del, it will pause other apps and allow you to open the task manager and choose one to kill.

On Linux? There's no task manager in the ctrl-alt-del menu (on KDE anyway), and even if there was it isn't a specially privileged UI so it wouldn't respond. Running low on RAM? No problem we'll just kill a random process and if that doesn't work (it usually doesn't), completely freeze and then hard-reboot. Yeay.


The Task Manager that many times also stopped responding or was permanently stuck behind a frozen full screen game?

On Linux, KDE has the plasma System Monitor, and if you can't use it for some reason you can switch your entire session to a TTY with CTRL+ALT+F2 and kill any process you want.


> you can switch your entire session to a TTY with CTRL+ALT+F2 and kill any process you want.

How intuitive. That's often disabled, and I've definitely had machines that were so frozen even that didn't work. I guess sysrq keys might have worked but if you're seriously going to suggest that you haven't understood the problem.

> The Task Manager that many times also stopped responding or was permanently stuck behind a frozen full screen game?

Hasn't happened once for me for as long as I can remember.

In fairness Linux has been pretty solid for me too after upgrading to 128GB of RAM and 64GB of swap. But I never needed to do that on Windows.


> Hasn't happened once for me for as long as I can remember.

I've had it happen to me, but the last time it did was probably around ~2017 or so on spinning rust. Fast SSDs make it a non-issue now.


Before you go adding vorticity confinement, consider performing a higher-order backward advection scheme (Runge-Kutta 2nd or similar), and using a higher-order interpolation method (triangle-shaped cloud instead of bilinear).

In my implementations I use 4th order for both and vortices stick around a lot longer.


If you implement this on the GPU, it's my understanding you can get the 4th-order interpolation quite cheaply exploiting the bilinear texture sampling hardware[1].

So instead of reading 16 grid values and combining them to get the interpolated sample value, you can fetch 4 bilinearly filtered samples and combine those. And thanks to the hardware filtering, those bilinear samples cost basically the same as reading an unfiltered value.

[1]: https://developer.nvidia.com/gpugems/gpugems2/part-iii-high-...


Yes, I do 4th order interpolation (M4') on the GPU. This paper is for 3rd order, though, but the methods may extend.

I suppose because the fetches are generally to similar memory regions, there may not be a substantial performance improvement due to L1 and L2 hits on recent GPUs.


You are correct: Stable Fluids extends to 3d relatively easily.

One of the nice aspects of Stable Fluids is that you don't need to iterate the pressure correction terms to convergence. Just run a fixed number of Jacobi or Gauss-Seidel sweeps and keep performance consistent. The only drawback of this is some mass loss in areas, which for the present purposes is acceptable.

I should add that this is a major "tell" for detecting when an app uses the Stable Fluids method: obvious mass loss (and very viscous, energy-dissipating flow).

Then you want Foundations of Multidimensional and Metric Data Structures by Samet. Unless you already have it, then enjoy some pretty (organic) trees.


Quadtrees and octrees are themselves quite deep research areas. If the acceleration data structures interest you, I highly recommend Hanan Samet's book "Foundations of Multidimensional and Metric Data Structures". It's from 2006, but is basically the bible for the field.


Note that even without an acceleration structure ("direct summation" in N-body research terminology), a CUDA program or GLSL shader program can exceed 60 fps with 10,000 to 20,000 particles. And a parallel, C/C++/fortran vectorized CPU code can do the same with over 5 thousand.


FPS is a poor metric anyway, things like this should be measured in frame time instead - but either are meaningless numbers without knowing the hardware it runs on.


Sure, I usually measure performance of methods like these in terms of FLOP/s; getting 50-65% of theoretical peak FLOP/s for any given CPU or GPU hardware is close to ideal.


The general algorithm used here (of computing attraction and repulsion forces between pairs of particles) is very similar to that used in simulations of many interesting phenomena in physics. Start with Smoothed Particle Hydrodynamics (https://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamic...) and then check out Lagrangian Vortex Particle Methods and other N-Body problems (https://en.wikipedia.org/wiki/N-body_problem).

And the algorithms to solve these quickly is another deep area of research.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: