There's a mindset difference. People are more willing to pay to reduce inconvenience for customers there, whereas here the inconvenience to the merchant sometimes matters more.
This simply isn't true, or you'd see these places accept credit cards.
The most prevalent mom & pop approach is either cash only or it's cash and PayPay. You may also see cash, PayPay and IC. PayPay, at first, had extremely low fees and an army of sales people that targeted mom & pops, pushing the low fees. They've since then increased fees as their saturation has increased, and now you'll see shops adding things like setapay or hachipay (which are annoyingly ku specific payment methods that are very low fee).
Larger businesses are owned by massive conglomerates, or are housed in shopping complexes owned by massive conglomerates that require them to accept more payment methods.
Like all businesses, they aim to reduce their costs and increase their margins. They aren't adding payment methods to reduce your inconvenience, unless they think doing so will increase their volume enough to offset the fees.
I remember a few American restaurants experimenting with this when I was a kid. I remember the experience being a little inconsistent. I imagine the feedback wasn't particularly good.
It's not the first. It's not even the first in Europe: the first was the UK, Belgium and Switzerland came after. There are and have been others around the world throughout history too: the CSA, the first USA, the USSR, the UAE, and the Arab League (just to name a few).
Most systems like the EU don't work well after a certain size. I don't know if we can say whether the EU has reached the point where it's unworkable yet.
The thing with the EU is that, worryingly, the less it works, the bigger it becomes (new memberstates, soon, Albania...) and the more power it takes on. This continent is heading for a catastrophic outcome and one must be blind to not see it.
That is not what the numbers suggest. Europe still leads in median quality of life and more healthy markets.
If you focus only on economic exploitation: Of course, with customer protection, companies can't do whatever they want. Of course business will develop less in comparison to countries where companies are free to do whatever.
It's not obscure. The reason is because a whole class of racist laws use the term. Nobody has seriously tried to reclaim the term, so it is stuck with the connotation it had developed a hundred years ago.
Genuinely curious which class of laws that would be.
I assume you mean in the US but the 1882 Chinese Exclusion Act makes no mention of race and anti-miscegenation laws speak of Mongolians(presumably to mean people of East Asian ancestry in general).
I think Oriental in the US like the alternative Asiatic applied to all Asians from Istanbul to Vladivostok.
There are 386 and 486 open source reimplementations in Verilog (see z386 and z486). As far as I know, existing commercial 386/486 chips still manufactured (yes they exist!) are descendants of Cyrix work, not Intel or AMD. Consequently, VIA may be contractually holding those back rather than Intel/AMD doing anything there.
Thanks for that information! I have been interested in getting x86 produced in smaller nanometer (e.g. <32nm). My project: https://ei2030.github.io/FemtoTX/#about
"Intel provided Rosaic access to an unknown Atom-class core, which enables the company to build its own custom processors based on x86 general-purpose cores, according to the report. The renowned chipmaker plans to ship Rosaic register-transfer level (RTL) code for the Atom processor core, which will let the startup build its custom system-on-chip (SoC) both at Intel Foundry and elsewhere."
What's interesting is that a startup with limited funds would most likely seek a 32-bit x86 license if a) they don't need more than 4GB of RAM, and b), if they don't want to pay AMD for the 64 bit license add-on. :)
I'll also point out that we've always had better starting points for open source high performance cores. SPARC and POWER both have open ISAs and open-source cores with useful performance. The UltraSPARC T1 and T2 processors were open sourced under the OpenSPARC project. POWER has the OpenPOWER project governing the Power ISA, and IBM itself created Microwatt, Chiselwatt, and the A2I/A2O cores as open source that people can build their own PowerPC systems from.
OpenFirmware came out of OpenSPARC and is also used by POWER too. Parts of it are used in ARM and RISC-V today (mostly DeviceTree, though arguably quite badly).
Nobody actually wants to make good cores for cheap. Nobody wants to make compatible systems unless forced to. That's why ARM and RISC-V are fragmented messes.
True, and the only reason I'm partial to x86 and even some older ARMv cores is that there is a huge existing software ecosystem already available, reducing the need to develop new bootloaders and ports, as coding hours aren't free. CISC cores are treated as if they are a dirty word, but are more versatile for covering various applications.
PowerPC at least still has a living ecosystem, even from the bootloader level. GRUB can boot from an OpenFirmware system. There's also yaboot if you hate yourself. ;)
I would personally love to see more Power Systems based projects. Everything is out there, just someone has to want to do something with it.
Fedora Linux even fully supports POWER8+ little-endian systems, and Fedora KDE offers a live ISO you can install on something like a Talos Workstation.
Yes, but compared to RISC-V neither OpenSPARC nor OpenPOWER are really going anywhere. Not really sure why, maybe the lawyers read the fine print about the level of openness they actually provide and decide that nope, not gonna touch that one?
Technically just looking at the ISA both SPARC and POWER seem fine enough. So why is nobody interested?
(Talos is interesting but not really an answer to the question, as it seems to be focused on building affordable-ish systems around an existing CPU, not developing new CPU's.)
OpenSPARC is under the GPL, which is probably why it didn't go anywhere directly. OpenPOWER is under permissive creative commons licenses, and people are iterating on the open source cores released by them. But the arrangement with efabless didn't go anywhere, and the company shut down last year without warning. So there's nowhere to experiment with producing chips.
x86_64 is itself well over 20 years old. You don't have to pay for it. And at this point SSE4 is on the verge of escaping patents, so a new startup might as well aim for that level. AVX is where you might run into patent fuss, but AVX isn't particularly important.
I had the same thought too months ago. In fact, I speculated the i840 GPU could also be integrated. Might the i915 GPU (GMA 900) also be ready for patent expiration?? https://inavoyage.blogspot.com/2026/01/the-nm10-chipset-back... although, the Sandy Bridge process would be ideal in terms of efficient iGPU integration.
It probably would have been less bad if he had chosen MPL-2.0 or LGPL-2.1-or-later. But he chose MIT, which cuts at the core of the intent of licensing the project with a share-alike license.
Tell me, can I create a copyrighted video that's not GPL licensed using ffmpeg?
Now tell me how creating a rust library using the git test suite is different?
But for the sake of argument: The test suite itself is copyrighted. To the extent the resulting work is a derivative of the test suite it is possibly infringing. For example you might example that the agent would derive variable names, function names, structure sequence and organization of the code from the test suite. It might even copy comments wholesale. Those are copyrightable things. (Which is of course just the first step in analyzing if it is infringement, there would be interesting fair use, de-minimis copying, etc arguments following a conclusion that any of those were copyrighted. A product produced this way definitely could be infringing given the right facts though).
yeah fair - the "The canonical Git source code we're targeting to replicate the functionality of is in the git/ subdirectory." part makes this hard to argue against.
> To the extent the resulting work is a derivative of the test suite it is possibly infringing
It's this bit that I have a problem with. If I run the test, it fails and reports a failure. Now I write code and run the test again. What is the theory there that code that I wrote infringes.
Doesn't infringe upon copyright period, because there's no creative element in that work.
Imagine a more substantial example though. Perhaps you have a test that checks that some file written in a binary format is correct, and gives names (creative elements) to each field of the format that it prints when you mess up the field, and has comments describing why the bytes are laid out like they are (the comments being copyrightable even if the facts they describe aren't), and the LLM copies those field names and comments verbatim... Now it's quite likely that the LLMs work is a derivative of the test suite.
For that assertion in particular I believe I'm practically parroting a ruling by the district court in Oracle vs Google about some extremely simple Java functions that Oracle claimed Google copied. Though I can't say I checked to make sure I'm remembering right.
You're recalling it right, but there's a nice quote from Judge Alsup in that case that talks about this exact situation:
> “So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification...”
Here given that this is rust and the original expression is C, the implementations cannot be the same by definition.
I'd challenge you here to think about this in terms of the legal aspects rather than reaching specifically for similarities as similar is often meaningless in the law or contracts when specific acts are codified rather than generalized ones.
I'd say what we're talking about here is probably a fair bit different to modding a game in most aspects.
I haven't followed any relevant cases but I would be surprised if there's any serious dispute that the common methods of modding games generally create derivative works. I think the dispute would be downstream of that as to whether or not the mods are covered by fair use.
If you did it in a loop until the test passed, maybe?
Your result is essentially impossible without the original. With ffmpeg, your result does not depend on ffmpeg specifically - you can use any video creation tool.
Repetition isn't really a factor in deciding whether something is infringing or not - check the copyright law in your jurisdiction. Here if you look specifically at what an LLM's sampling stage is doing, it's choosing non infringing tokens (i.e. rust source code) over infringing ones (i.e. C source code). So it's making an intentional choice to do something similar rather than creating something that has the same expression. That doesn't seem like it's copyright infringement to me.
A GPL tool that processes data doesn't virally transfer the license to its output. Copyrighted ffmpeg code isn't incorporated into the video output. The LLM didn't just conjure up equivalent behavior to git without ingesting the code and transforming it as new output. There is no other behavioral description that would reproduce all needed functionality.
It would be reasonable to point an LLM at these and use them with a basic knowledge of git to produce a rust version of git in a non-infringing manner.
If you did this manually it would take a long time.
Substitutibility probably doesn't apply here in the way you're implying and if it did it would likely be hampered by the 9th circuits findings about transformation in sony v connectix. Arguments here likely would look at rust not having a stable ABI, and hence not being inherently substitutable as a libray (grit-lib), less clear as an executable (grit-cli) on that side
basics of copyright law - the fundamental thing being protected is the expression... is a rust program's expression the same expression as a c program? I'd say generally not.
The test suite could test aspects of the architecture/design of the codebase that are not necessary for interoperability and constitute novel expression of a piece of software in a way that is not at all language specific.
By definition a test suite is about testing interoperability with the test suite. An HTTP test suite should likely test for whether response code 418 is implemented a particular way and while humorous it would still be an interop test no?
