Hacker Newsnew | past | comments | ask | show | jobs | submit | aa-jv's commentslogin

We could have more ASML's immediately if we eradicate the desire to covet technology for one in-group, over another.

> reshaped society

Invalidate all of ASML's patents = get cheaper chips, sooner.

It is intellectual property which gives some of us the ability to build these things and sell them to others - get rid of this phony concept and we can have more nice things...


The article might disagree. See the subsection, "The importance of tacit knowledge". OTOH, if that tacit knowledge is indeed so critical then there's less risk (e.g. regarding future investment incentives) to narrowing patent protections. OTOOH, ASML's supply chain is deep and complex, and the patent portfolio is presumably similarly diffuse, which makes it difficult to analyze or even, short of a complete patent regime overhaul, identify which patents to open up to accelerate adoption.

ASML's supply chain is deep and complex - and secret. But if it were F/OSS (just imagine it) from sand to chip, that complexity would have a wider scope of human attention applied to it.

What is happening with ASML now, once happened with the wheel.

Think about that.


Patents are supposed to be the antidote to industrial secrets. Of course, it doesn't really work out that way because in addition to patent writers hiding the ball or strategically layering patents and secrecy, things like tacit knowledge and organization play a huge role in exploring, building, and applying solutions. FOSS doesn't really help with the tacit stuff. It's partly why it's so difficult for projects to survive after the original authors move on. With software that's not necessarily immediately fatal as long as the software works well and is easy enough to tweak around the edges to keep it compiling and interfacing well, qualities which FOSS is meant to foster and preserve. But outside software, and especially in the industrial sphere, the loss of that tacit knowledge and organization is often immediately fatal. You can't just copy stuff, you have to rebuild all that tacit knowledge and process. Often times, like in software, the resulting product that nominally achieves the same results is built around an entirely different technical approach.

Or you could have nobody bother to invest in things like this because of no reward, or they become closely guarded trade secrets of which the Elves keep and nobody else is even allowed to know they exist.

"no reward" is weak, because of course you wouldn't make a wheel, say, unless you intended to roll somewhere.

You're basically saying "ASML's entire production line is worthless unless it is rare and coveted", which is .. obviously not true .. because of course the output is immensely useful.

The world needs more chipfabs, not less. A properly scaled chipfab in places like Broome or Santiago, or .. indeed in orbit .. would go a long way to sorting out the worlds fires.

The thing stopping us, is the international, imperial system of patents and intellectual 'property', which make nation states subservient to each other on the basis of ideas.

The ideas could be spreading far and wide, but we humans are keeping them in our cage, in which the only reward is having other cages to extract wealth from ..


And if you had done that 10 years ago we wouldn’t hve EUV at all. You’re proposing ending future development to make today’s products cheaper.

That's a great way to lower the cost of the current generation of the tech while ensuring there is no next generation of the tech.

I don't think that makes any sense whatsoever.

If everyone could make these machines, there'd be more of these machines.

There are so many examples of this out there, already, that I find this specious "no next generation" argument to be either simply coming from bias, or ignorance.

For sure, we only care about Taiwan because there is one Taiwan. End patents: no more Taiwan problem.


> If everyone could make these machines, there'd be more of these machines.

My post is in violent agreement with this, for this generation of machines.

ASML spends ~$5B annually on R&D with the expectation that they will be able to make ~30% net profit in the future. If you remove patent protection, there will be more competition and obviously profit margins will fall.

I want to rephrase that for emphasis. The point of aa-jv's post was that we would get cheaper chips by invalidating IP. Cheaper chips means lower margins (because you have not lowered input prices). Lower margins was the explicit goal, so to the extent that the changes in IP law work, you will get lower margins for companies like ASML.

At that point, you have a field of companies looking at (say) 10% net returns, still needing to invest billions of new capital into R&D every year. Worse: no patents means that Company A could spend $5B on R&D and Company B could spend $0, and both of them could reap the benefits of that $5B by Company A. So it's not even necessarily clear that the industry would see much net innovation.

Are we even certain there are companies who would enter this capital-intensive business assuming IP was free? Compulsory licensing is a thing, but I am not aware of that even being something that has been requested.


No, its emphasizing that the size of the shipment necessitates multiple high capacity logistic steps.

Hot take: We're in the first stages of building our own Dyson sphere and therefore comets are only useful in the context of capturing them for that purpose.

;)


Its not the default because that'd be counter-productive to developers who use git with larger repositories, which is how git started life in the first place - your clone depth would be entirely useless for Linux kernel developers, for example, if it were default ..

I've always wanted to see a book that describes git for the common man and gives them tons of examples for how to use it to do productive things.

Even for a small office, git can be immensely useful. Entire production line workflows can be implemented with git .. if only folks would learn to use it productively.

Its not just for development. Writers can use it productively. Accountants too.

It always kind of irks me that Git hasn't just been folded into the OS front-end UI by any of the OS vendors .. it'd be so revolutionary to give common folks an easy way to manage the timeline/history of their computer use using git.


The thing is that change tracking and sometimes even full-on version control are actually integrated with a lot of the tools that people use, like your document editor. The incremental benefit of git then would largely not be automatic version tracking but only the interactive history browsing which git itself is kinda meh at (and is of questionable value for a lot of workflows). And the cost of this transition is forcing people to use a different tool from their regular workflow, one that wants to be used in an environment they're not comfortable in, and also one that is not conducive to handling anything other than plain text.

Rather, programmers should learn from how other software handles version control and incorporate those ideas into git instead. For example, perhaps we should automatically create a commit every time we build the project so that we can roll back or forward to previous builds and not rely on the programmer to remember to make commits so frequently.


The obvious reason is that most file formats used by writers, accountants, etc. are binary files which do not very much benefit from git.

Microsoft Office files are zipped XML these days, there's a standard and everything.

So? Doesn't matter. Git in that case still provides valuable historical archiving and versioning that is still more useful than the option, without it.

Plus, its chicken and egg. If the OS had a great interface to Git as part of its responsibilities in the Explorer/Finder interface, folks would be more inclined to use text-based file format standards that are coherent with the Git methodology.


Parse /proc/<pid>/maps to find the relevant target_addr in your process-under-attack. And then its a matter of:

    $ dd if=shellcode.bin of=/proc/<pid>/mem bs=1 seek=$((target_addr)) ...
See also: DDExec

https://github.com/arget13/DDexec


What legitimate purpose does this feature serve? Why should a process be able to write into the virtual memory of another process?

Like it says in the preamble on the site, don't think of this as a collection of exploits, but rather as a compendium of knowledge about escalation techniques for use in emergencies.

I can't tell you how many times I burned my fingers as a young Unix developer in the 80's by untar'ing things wrongly, or fat-fingering an 'rm -rf /' and thus having a running system that will be catastrophic if I don't fix it before reboot, shell still active and .. what do? Consult this list of great advice and use it to rebuild the system and/or do things that need to be done that otherwise wouldn't be possible ..

GTFOBins is not just for hacking. Its also for system repair and recovery. I'd be as likely to consult this knowledge base after a hacker attack as before, if not more ..


Ouch, thats pretty average, what a pity ..

That's the maximum delay when adding a delay for synchronising with other sources.

The end-to-end delay is about 10ms, according to this comment:

https://www.audiosciencereview.com/forum/index.php?threads/i...


Why? This is a device more for home audio/audiophile uses it seems? Why does latency matter there?

Audio systems get used for more than playing back music and film soundtracks.

People use audio system at home to play electronic instruments. People also play video games. People do all kinds of stuff.

Latency is an important factor in these things.

Even videoconferencing and podcasting: With a microphone pointed at your face and a set of headphones used for monitoring that microphone, latency matters.

(It matters more to some people than others -- some people can tolerate hearing themselves later and continue to speak just fine, while some others increasingly sound like they're having a stroke as monitoring latency goes up and eventually become unable to produce coherent strings of phonemes.)


Huh thanks for the info! I didn't know about any of this at all. Latency sounds like it could be an important consideration for some people.

Would be nice to use it as a synthesis DSP if the latency were a bit better.

Interesting that this was discovered after embarking on a journey to understand how widespread the use of Lua is, in the exploits realm ..

I also wonder why they opted to make this an injectable worm and not just a side-loaded 'feature' of the OS?


What would the difference be? They would have the same effect.

Easier to deliver as an OS bundle, no worm required.

Killing children and justifying this form of murder by calling them terrorists takes a higher toll, imho.

Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: