uguuo_o

I'm just relaying what most guitarists that have played with him have said. Watch a few interviews, jazz, flamenco, whatever he plays.

Here an example of his playing: https://www.youtube.com/watch?v=C97H_HvBjPA

30 years playing guitar, I believe I can recognize masters, but this guy is just wow.

Just a minor note. Howe is good, one of the best yes, but Paco De Lucia reigns far above them all.

I have a few from schitt that have been pretty solid for years, I highly recommend them.

https://www.schiit.com/

Yes, it just means you have to solder the switches yourself. From their website:

This is a special version of Glove80 meant for users intending to replace key switches. Soldering is required for this keyboard to function.

This looked so good until I saw it requires switches to be soldered (by them or you). Hot-swappable switches is a must for me, specially at this price point. I guess my ergodox will have to last a bit longer until a proper replacement is found.

Thanks for the suggestion. Good luck with your project.

I tried to use it but I had some issues as others in the thread.

I have tried many sources and method over the years and settled on spleeter [0]. Works well even for 10+ minute songs, varying styles from flamenco to heavy metal.

[0] https://github.com/deezer/spleeter

Not to be confused with the Ansys flow solver Fluent:

https://www.ansys.com/products/fluids/ansys-fluent

This is the only combination I also went with, nothing else seemed acceptable on the android side. GrapheneOS has been fantastic, no Google apps.

Yes. The librem 5 is a somewhat solid alternative. The pinephone seems to remain a developer platform as it lacks simple features expected out of a phone.

It is not a single language. c, C++, Fortran are the most commonly used. The communication happens using one of many versions of the message passing interface [0] (MPI). MPI essentially spawns child processes and a communication ring between nodes using whichever interconnect is available (usually infoniband).

[0] https://en.m.wikipedia.org/wiki/Message_Passing_Interface

It sounds like what you want is graphene os.

https://grapheneos.org/

Even emacs has a markdown mode:

https://jblevins.org/projects/markdown-mode/

Large-scale simulations of phisical systems tend to have a variety of length/time scales that require vast numbers of CPUs to model in a timely fashion. This could be anywhere from a few hundred cpus to tens of thousands. Fluid dynamics, solid mechanics, fluid-structure interactions, electrohydrodynamics, etc. simulation tools can all benefit from having a larger number of highly interconnected CPUs, we can simply resolve engineering problems better with more computational resources for better understanding of problems.

Reasons : there is a significant amount of work needed to get codes to work on a distributed hybrid or gpu-only fashion. It's a completely different coding paradigm that needs significant studies before commercial entities adopt gpu use at scale. All-gpu solvers are starting to be developed, such as fun3d GPU[0], but features are very limited. GPU development is starting to catch up in the community, so it won't be long before a significant portion can operate heterogeneously or in gpu-only mode.

[0] https://fun3d.larc.nasa.gov/GPU_March_2021.pdf

The amount of scientific work that could be done with such a machine would be staggering, specially if it can be local. I use 2-10k cores on a daily basis, having a dedicated machine with 1k would make debugging large scale problems much faster.

I will vote against this in any way I can for as long as I live.

Yes, the cost is on the high side at the moment. It is impractical, but it may be the only choice we ever have if we do not want an internet connected vehicle.

A poorly-optimized code that does not scale is not evidence that all simulation tools behave the same. Most of the tools in use by NASA, DOD, DOE, research institutions and commercial codes scale very well. Weak and strong scaling both. In fact, scalability is one of the primary requirements for simulation tools that are used in mission critical environments. I've been the technical lead for many of these types of projects, and I have experience with most of the largest commercial, research, and open source simulation codes. The vast majority of parallel tools scale linearly well beyond the 10s of thousands of cores, and I do agree that at some point adding cores can cause bottleneck, but that point is usually far past the few hunder cores from your link for a significant portion of engineering applications.

It is common knowledge in the field to optimize a simulation for the largest number of cores it can efficiently use, so simulation cases are not just blindly thrown more cores without a justification given by the scalability. Your initial claim that parallelization doesn't get you much is flawed, parallelization is the only thing that enables scalable engineering analysis.

Forget side-loading, the fact that I can't develop and run my own applications on iOS without having to ask apple for permission every week is infuriating.

Depending on the method, but generally yes, the physical domain is decomposed into the number of cores. Data is synchronized at processor boundaries at a very high rate to maintain consistency.

I am not sure where you get this information. Parallelization is everything in this space, hence why we have highly interconnected supercomputers to model the most difficult engineering problems. Typical runs use 30k+ cores for a single problem for weeks on end [0]. There are some special cases, such as Boltzmann/dvm [1] where invididual partitions of cells have millions of degrees of freedom, where memory bandwidth is the primary concerns. Even then, doing domain decomposition to a larger number of cores takes care of the issue.

[0] https://www.nas.nasa.gov/SC22/research/project12.html

[1] https://www.sciencedirect.com/science/article/abs/pii/S00219...

On scientific computing (computational fluid dynamics, computational electromagnetics, etc.), parallel programing is a must. Most of the algorithms are not embarrassingly parallel, and need a significant amount of communication between threads during runtime. We mostly use one of the many MPI [0] libraries available for desktop and high-performance computing machines. Using these programming paradigms is difficult but tend to result in fantastic scalability for all types of engineering problems.

[0] https://en.m.wikipedia.org/wiki/Message_Passing_Interface

For those on Android, there have been app alternatives for a while [0]. Without these, I would have stopped watching content on my phone years ago.

[0] https://github.com/gilbsgilbs/NewPipeSponsorBlock

I thought I had just seen a post yesterday [0], so I immediately thought how can there be 2 such lawyers? Competition on who would get caught first? It seems to be referring to the same case.

[0] https://news.ycombinator.com/item?id=36116652

This article reads as if the car itself is responsible for the crash, not the driver.

As a firefox user of a couple of decades, I am now starting to look at alternatives. Anything chromium is a big no, but there are few alternatives. Perhaps it is time to go back to using Lynx.

After their superfish debacle [0], I just have not been able to give them my money regardless of how great some of their machines are. Maybe someday.

[0] https://www.tomshardware.com/news/lenovo-settlement-superfis...

This problem has been known for a long while. The models used here by Metzger have such a large uncertainty and only take into account erosion due to shear. As soon as the erosion transitions from shear-based (smooth sheets) to bulk (fluidized), none of the data extends to that regime. A massive vehicle landing on the moon will definitely cause fluidization. To estimate erosion and ejecta needs far more detailed numerical methods [0].

[0]https://doi.org/10.1017/jfm.2021.29

I think he is still a terrible drummer. Hs style, whole somewhat unique, lacks technique by a whole lot. As a drummer, Metallica's songs are pretty easy to play even for intermediary players. There are far better drummers, one of my favorites being Priester: https://youtu.be/rZCm1Kz1PVY