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

Some people tried it and got sued for patent infringement (ASML vs XTAL)[1]. ASML patents all EUV-related technology, so you'd have to come up with a brand new way of generating EUV plasma at high energies at constant rate. Even ASML had to buy an American company Cymer to get a working prototype. Then, because EUV radiation doesn't pass through air or standard lenses, you'd have to come up with another optic column system. If you want to go 5nm and below, you need anamorphic lenses/mirrors with almost atomic precision [2]. ASML gets these columns and lenses/mirrors from Zeiss, but probably has patents on their practical application.

The sheer size of the supply chain you need to create to make a working machine is massive. It's one of the reasons why ASML got ahead of the Japanese companies that tried to do everything in-house.[3][4]

It took 17+ years and €6 billion in R&D to get EUV working [5] (as such EUV litography became feasible in the 90s), so ASML's leading position on the market is justified. They have to recoup all the costs, so they will make sure to keep the market leadership through all legal means.

My guess is that if someone would come up with a more efficient EUV plasma generation or better optic systems, ASML would acquire the company and take over the technology.

Regarding the negotiating power, some companies like GlobalFoundries couldn't afford ASML's EUV machines, so they parked their EUV plans [6]. It's only big players like TSMC, Samsung and Intel that can afford this tech and all these companies know their worth and prices. ASML needs money to pay for the R&D and can't afford to lose it's biggest customers that are also buying their non-bleeding edge technologies (DUV litography).

I don't know the business side of things, but it's definitely going to be interesting to see what happens with competition in the EUV litography in the upcoming 10+ years.

EUV litography and silicon-based chips have their physical limits, so there might be other ways to continue improvements.[7]

[1] https://www.reuters.com/article/us-asml-holding-xtal-court-i...

[2] https://semiengineering.com/extending-euv-to-2nm-and-beyond/

[3] https://ideas.repec.org/p/eti/dpaper/05007.html

[4] https://youtu.be/SB8qIO6Ti_M?t=673

[5] https://www.asml.com/en/products/euv-lithography-systems

[6] https://www.anandtech.com/show/13277/globalfoundries-stops-a...

[7] https://semiengineering.com/making-chips-at-3nm-and-beyond/


EUV and higher energy photons are difficult beasts, I would put my money on electrons next, so perhaps the electron microscope companies hold the interesting patents there.


E beam lithography in credibly difficult. Recommend chapter 13 in "Principles of Lithography" https://spie.org/Publications/Book/2525392?SSO=1.

My opinions is that this whole comment discussion about creating a competitor is in the wrong direction. It is impossible to recreate and outperform what ASML has.

A better focus would be to tackle problems in the <2nm processes. If someone found a method to stop electron tunneling at smaller nodes, this will net much more revenue and create more value for society.


Those kernel modules (`ashmem` and `hwbinder`) are standard when building the Linux kernel for Android and they are already part of the upstream Linux kernel tree [1][2]. Because this solution uses containers (which share the same kernel with the host OS), these additional modules are needed.

From the ReDroid kernel modules readme:

>Custom Kernel

>If use custom kernel (5.0+), you can enable binderfs and ashmem configs; So the kernel modules in this repo are not needed any more.

https://github.com/remote-android/redroid-modules#custom-ker...

More info here on Android-specific kernel modules here:

https://elinux.org/Android_Kernel_Features#List_of_kernel_fe...

[1] ashmem

https://github.com/torvalds/linux/blob/master/drivers/stagin...

[2] hwbinder

https://github.com/torvalds/linux/tree/master/drivers/androi...


It's just a parameter to let the Android OS know that it's running in an emulated environment as opposed to running natively on a physical device.

For example, the GPU stack has to be somehow emulated using a custom OpenGL driver (in this case `mesa3d`). There's software emulation (swiftshader) and host GPU mode (GLES).

For performance reasons when using the host GPU, the GLES commands from the guest have to be serialized and sent over a kernel pipe to the QEMU and to the host OS. The commands are deserialized on the host and executed on the physical host GPU through the Shader Translator library (taken from the Google ANGLE project). The Google's QEMU fork (aka Android Emulator) usually loads this library and then takes care of proper rendering, such that users can see the rendering output of the emulated OS properly inside the emulator window on the host machine. You can do the same for the docker, otherwise you'd have to implement some other trick to share the GPU. `virtio-gpu` is a Linux kernel facility that is meant to replace QEMU pipe in the future.

The high-level details of this OpenGL emulation mechanism are described here: https://android.googlesource.com/platform/external/qemu/+/ma...

You can find the implementation of the QEMU OpenGL pipe mechanism here: https://cs.android.com/android/platform/superproject/+/maste...


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

Search: