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

> IDK if RAM chips are also on that list.

Apple cancelled their deal with YMTC (Chinese RAM company) after the US sanctioned the latter. I don't know whether that is directly because of the sanctions, or indirectly (e.g. if Apple thought sanctions would hamper YMTC's ability to supply the goods), but they have had the same effect.

https://www.lightreading.com/business-management/chinese-chi...

https://www.business-standard.com/article/international/appl...


But they support extensions on desktop.

The problem you linked to also happened on desktop because there is no VSCode for phones.


I am glad someone is putting in this effort. Many years ago, there was another project called GIMPshop to make GIMP's interface more accessible to Photoshop users.

https://en.wikipedia.org/wiki/GIMPshop

They taught Photoshop at school, so I found it easier to use GIMPshop than regular GIMP.


That's actually what I thought this submission was. Didn't remember what it was called, so I didn't realize PhotoGIMP wasn't GIMPshop.

It's funny that both of these kept GIMP in the name when the name itself has spawend a different fork.

I remember one renamed Glimpse but it seems they stopped working on it long ago: https://github.com/azubieta/Glimpse

Yes, none of the forks have succeeded so PS interface compatibility may not be as important as is constantly mentioned.

There was also an effort called Glimpse around 2019 to be a UX / accessibility overhaul of GIMP along with a name change to be less offensive, see:

- https://github.com/joshgiesbrecht/Glimpse

- https://web.archive.org/web/20190829115212/https://getglimps...


Looks like the last release was from over a year ago and the issues indicated it no longer works with the latest GIMP release.

> Friends don't let friends use sites like this.

Why not? The download link on the site points to to Microsoft's official website.


> They have no rights to prevent people modifying and using AGPL software however they want.

AGPL software can be used and modified within the limits of what the AGPL permits. People can do that with their Bambu software running on their own hardware.

That does not extend to using their proprietary BambuNetwork cloud service (somebody else's computer). The AGPL specifically mentions this scenario in section 6. There are open source alternatives to that like the third-party Bambu-Farm and bambuddy that people can self host instead.

Interestingly, Bambu's own initial approach to the AGPL was more in line with "modifying and using AGPL software however they want" (and potentially violating their section 6 obligations), until customer backlash forced them to adhere to the terms of the licence.


Id Louis Rossman's YouTube rant is correct, nobody involved here modified the AGPLK software. They just used a version of the AGPL software from before Bambu Labs changed the auth code.

While I agree that the AGPL does not grant users any rights to Bambu's cloud service, sending DCMA nastygrams to people hosting copies on old versions of their software isn't the right (or even legal) way to enforce that. And since Bambu choose to build their products and software stack on pre existing AGPL code, they've backed themselves into a corner a bit with other options. They can add new auth to new versions of the code (which is stringer than just hardcoded useragent-like strings in the code) but they'll then have to release the source code to their new version - exactly like the original authors who chose the AGPL intended.


If I just build the software from their repo without any modifications, getting an identical result to what I can download via their website, would I be allowed to use the service? If not, why not? If yes, what if I made a modification? How much may I change and where was this ever codified? What about using an unmodified, prior version of the source code to build? Why would that not be ok?

Interesting question. In the first case, where you install your own build from unmodified source code, although AGPLv3.0 still allows discontinuing support, I see no explicit carve-out in the licence to restrict network access.

However, the AGPL comes with no right to such network access to begin with. Permission to access the network would usually come separately from the AGPL; I suppose you could potentially bundle it as an additional permission under section 7, but I don't think Bambu is doing that.

To take it a step further, even if you use the latest official software, installed by the vendor (and not by you), they can still refuse you access to their network. That might violate some other agreements or laws (e.g. contract to provide a service), but it does not violate the AGPL itself.

What they cannot do is prevent you from running your modifications on your hardware.


But they had no access control in the first place. If I built their repo without modifications, I automatically have access. I would need to make modifications not to get that access.

> [...] they can still refuse you access to their network.

Sure, they can and yes, AGPL doesn't give users right to just access services, I have said before that they may enforce their EULA upon individual users. They are however not doing that, they are harassing repo owners. Let me put it this way: If the network access were the issue, as you seem to think, why go after the dev hosting your code rather than the individual users that you claim improperly access your services.

> What they cannot do is prevent you from running your modifications on your hardware.

They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.

That's why I was asking specifically regarding what level of code modifications is acceptable for them. Because they made this an issue not about using their servers but hosting code, regardless of how it's used.


> They also cannot prevent a developer from rehosting AGPL code, but they are trying to do that. And it's kind of the actual issue.

I agree. I think the argument they are going for is similar to that from Google against yt-dl, but unlike in that case, Bambu is obligated to allow this codebase.


> That does not extend to using their proprietary BambuNetwork cloud service (somebody else's computer)

As I said, I believe people have a right to "adversarial interoperability", so I respectfully disagree


You can run modified software per the GPL but that does not include the right to connect to Bambu's servers with your modified software. That is entirely reasonable (especially since this is not some social/messaging application). If I release a client as open source, that doesn't mean it's OK for modified clients to connect to my server. I expect you to use it offline or set up your own server to connect to.

I don't know if that is what is happening here because the article is talking about a fork that is bypassing Bambu's servers entirely (which is permitted under the AGPL) and Bambu is not happy.

Edit: On re-reading, it seems to me the fork is still calling Bambu's servers. It's just bypassing some things.


You must put authorization on your server if you don't want others connecting to it.

While the right of access is not granted by AGPL - it is not reasonable to run a public service with an AGPL client and say you shouldn't be connecting to it.

They are doing a lot of work to create implied consent under CFAA.

If you want to control access you must do something to control access - it must reach a threshold, it cannot just be a public user agent string.


> You must put authorization on your server if you don't want others connecting to it.

Unfortunately, the CFAA doesn't necessarily require that authorization is implemented through technical means, and it definitely doesn't require any authorization to be technically robust.


The point is that they distributed AGPL licensed software which legally speaking puts them on very thin ice if they say "actually you're not allowed to modify that software we gave you and explicitly told you you could modify to do whatever you want."

This is a direct quote from the Affero GPL:

> When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

The thing Bambu is doing is very much against the spirit of the AGPL, which is the license they chose for the Bambu printer software. And the AGPL has such broadly written language it's hard to believe what they are doing complies with the letter.


You're certainly allowed to modify the software, but that doesn't necessarily give you the right to connect it to hardware owned by other people. And AGPL does not provide for any right to services -- only a right to use and modify the covered work.

For example, AGPL doesn't prevent you from being banned from a Mastodon server.

The key part of the sentence you quoted is "... to the extent such circumvention is effected by exercising rights under this License with respect to the covered work" -- meaning, you can't use anti-circumvention to prevent people from using or modifying the copyrighted code.


Again, legally that's correct. But it goes completely against the spirit of open source and especially the GPL which says in the license itself that "our General Public Licenses are intended to guarantee your freedom to share and change all versions of a program". If you can't run a modified version of a program without getting sued, you practically speaking do not have the freedom to modify it.

Elsewhere, the GNU explains why this is important[1]:

> With proprietary software, the program controls the users, and some other entity (the developer or “owner”) controls the program. So the proprietary program gives its developer power over its users. That is unjust in itself; moreover, it tempts the developer to mistreat the users in other ways.

> [...]

> Freedom means having control over your own life. If you use a program to carry out activities in your life, your freedom depends on your having control over the program. You deserve to have control over the programs you use, and all the more so when you use them for something important in your life.

Telling your users they can't run modified versions of your open source client goes against this principle.

Again, I'm not necessarily saying Bambu isn't within their legal rights to do this, I'm just saying it's a jerk move.

[1]: https://www.gnu.org/philosophy/free-software-even-more-impor...


You can also embed references to OpenClaw in the compiled binary to dissuade AI-assisted decompilation.


There are some projects to port UEFI to boards like Orange Pi and Raspberry Pi. You can install a normal OS once you have flashed that.

https://github.com/tianocore/edk2-platforms/tree/master/Plat...

https://github.com/edk2-porting/edk2-rk3588


There also seems to be a plan to add uefi support to u-boot[1]. Many of these kinds of boards have u-boot implementations, so could then boot uefi kernel.

However many of these ARM chips have their own sub-architecture in the Linux source tree, I'm not sure that it's possible today to build a single image with them all built in and choose the subarchitecture at runtime. Theoretically it could be done, of course, but who has the incentive to do that work?

(I seem to remember Linus complaining about this situation to the Arm maintainer, maybe 10-20 years ago)

[1] https://docs.u-boot.org/en/v2021.04/uefi/uefi.html


Per TFA, the Orange Pi 6 Plus ships with UEFI, but the SoC requires a vendor specific kernel.


The orange pi 6 plus supports UEFI from the get go.


Inflation is about what goes on inside the country. So you can have inflation internally while the domestic currency strengthens against foreign currencies, and vice versa.

If your currency is falling against foreign currencies but prices are also dropping domestically, you get deflation. This was happening in China a couple of years ago, and they were exporting this deflation to other countries.


The mathematical field of tackling number theory problems in this way is called analytic number theory.

https://en.wikipedia.org/wiki/Analytic_number_theory

The prime number theorem, on how prime numbers are distributed amongst the integers, was first proved using analytic techniques.


Analytic number theory exists and involves calculus, but it's not what the linked post is about. The article talks about Hensel's lemma, which is a purely algebraic statement with a purely algebraic proof, which, however, is inspired by techniques from calculus. This is typically still categorized as algebraic number theory.


Get a load of number theorists in a room and there will always be a fight between the analytic and algebraic.


Hensel's lemma is an analytic fact about the radius and speed of convergence of Newtons method in the p-adics.


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

Search: