Before my actual comment, I just want to humorously remark about the group which found and documented this vulnerability, Legit Security. With a name like that, I would inadvertently hang up the phone if I got a call from them haha:

"Hi! This is your SBOM vendor calling. We’re Legit.

Me: [hangs up, thinking it’s a scam]

Anyway…

In a lot of ways, this is the classic “ignore all prior instructions” type of exploit, but with more steps and is harder to scrub for. Which makes it so troubling that GitLab’s AI isn’t doing anything akin to data separation when taking instructions vs referencing other data sources. What LegitSecurity revealed really shouldn’t have been a surprise to GitLab’s developers.

IMO, this class of exploit really shouldn’t exist, in the same way that SQL injection attacks shouldn’t be happening in 2025 due to a lack of parameterized queries. Am I to believe that AI developers are not developing a cohesive list of best practices, to avoid silly exploits? [rhetorical question]

I don’t think that’s the main objective of the FUTO license

That’s fair. I stated my assumption because perhaps they have different objectives. That said, history is quite clear: the greatest success of open-source software development is that it pools efforts from anyone – truly anyone – that is willing and able to put in the time, be it individuals or workers hired by a corporation.

When a license is heralded as an alternative to open-source – as the title of this post does – I think said license needs to be evaluated against the historical success story that open-source projects like Linux, BSD, Blender, etc have demonstrated. Not having the quality of attracting community contributions is a negative, but all licenses have some sort of tradeoff and ultimately that’s what people evaluate when picking a license.

I believe the main objective is to incentivize developers to create great software that respects individual users and fights back against the big tech oligarchy.

This is a laudable goal, though I think the ACSL is more direct at doing the same. It too is a non-open source license, but IMO, I give credit to them for being upfront about that, rather than pointless muddying of the term “open source” that Futo attempted (and ultimately failed at).

More dogmatically, I don’t see how elevating Futo Holdings Inc (or any other company that will manage software licensed under Source First v1.1) into a “benevolent dictator company for life” will fight against the tech oligarchy. It might act as a counter to FAANG specifically, but there’s no guarantee that Futo Holdings doesn’t end up joining their side anyway, or gets bought out by the oligopoly. Which would then put us all worse off in the end.

I don’t quite see the issue here. Can you explain a little more? A third-party would just get a license to sell the software, not to develop it.

Futo Holdings Inc, as the assigned owner of copyright over a software project, reserves the right to license their software however they choose. They can absolutely issue a license to allow a company to privately develop an in-house fork. In copyright speak, the Source First license being “non exclusive” means Futo Holdings can issue someone else a different license. History shows us examples, such as Microsoft’s non-exclusive license of DOS to IBM, which was quite handy since that allowed MS-DOS to be sold with non-IBM PC clones.

And for an example of licensing that allows in-house edits and recompiling, see the source code license offered by AT&T Labs to various universities, which included one UC Berkeley that eventually developed BSD Unix.

Isn’t this currently possible with Open Source™? Like the whole point of Open Source™ is that anyone can use the software for anything, right?

Use, yes. Distribute? Absolutely not with GPL. If ICE wants to create an OS designed to optimally coral unlawfully-detained people in barbaric conditions, then they – just like you, me, the DPRK, or Facebook – can fork Linux and do that. But if ICE then wanted to distribute that CruelOS to another country’s border patrol or secret intelligence or to a private defense firm, they would be obliged by the GPL terms to also offer whatever source code they modified in the Linux kernel to produce CruelOS.

GPL is about making sure the same rights perpetuate for all of time, for all future users, always. If Linus Torvalds turned evil today, the remaining kernel devs would just fork. Whereas Futo Holdings makes no guarantees, and they themselves can turn evil one day. This isn’t even a contrived example. See IBM/Hashicorp’s Terraform and the FOSS OpenTofu that spawned after they tried to change the license.

Google may contribute something to Linux, but my company will never contribute anything. Seems like Google is ok with my company benefiting from their work.

If Google contributed to Linux, it would be GPL licensed. Google knows that this means the playing field will always be level: no one can built and distribute that code in a way that Google couldn’t later benefit from.

Think of it like this: Google buys everyone in the tavern a beer. Everyone’s happy. But part of the deal is that if anyone else buys for themselves a beer, they have to buy for everyone as well. Google is fine with this, because it means that Microsoft wearing the dark suit will also have to pony up if he wants another drink. As will Netflix in the skinny jeans sitting at the booth. As would Ericsson, the Swede dancing jovially to a tune.

With the Source First license, Google has no guarantees that Microsoft won’t use his manly charisma to charm Futo Holdings into giving him a better deal than what Google got. Google is bitter at that prospect, and decides not to buy everyone a beer after all. You, me, and Bob who fell asleep in the corner now need to pay for our own beers, but the bartender won’t give us a group discount anymore. We are now all worse off.

In closing, I had this to say in an earlier post:

Using the tools of the capitalist (copyright and licenses) to wage a battle against a corporation is neither an even fight, nor is it even winnable. Instead, strong communities build up their skills and ties to one another to fight in meaningful ways.

If you’re not building (software) communities, the struggle will not succeed.

I’m not sure how this license would foster community contributions to the codebase, assuming that was an objective. When I say “contributor” I mean both individuals as well as corporations, in the same way that both might currently contribute to the Linux kernel (GPL) today.

As written, this license grants the user a non-exclusive license for non-commercial use. But that implies that for commercial users – like a corporation – they’ll have to negotiate a separate license, since Futo Holdings Inc would retain the copyright. So if a corporation (or nation state entity) throws enough money at Futo Holdings Inc, they can buy their way into any sort of license terms they want, and the normie user can’t complain.

This is kinda like the principal-agent problem, where the userbase and individual developers now have to trust that Futo Holdings won’t do something reprehensible with the copyrights, be it licensing to certain hostile countries or whatever.

Whereas in the GPL space, individual developers still own their copyright but license their code out under a compatible license. So even Linus Torvalds cannot unilaterally relicense the Linux codebase, because he would need to seek out every copyright owner for every line of code that exists, and some of those people are already dead.

I’m personally not a fan at all of forcing individual contributors from the community into signing over copyright (or major rights thereto) or other stipulations as a condition for making the codebase better, with the exception of an indemnity that the code isn’t stolen or a work-product for hire. I used GPL in the comparison above, but the permissive licenses like MIT also have similar qualities.

EDIT

Thinking about it more, would corporations even want to contribute? Imagine CorpA decides to add code, having already paid for an existing commercial license from Futo Holdings. But then CorpB – who is CorpA’s arch nemesis – pays Futo Holdings an absurd amount of money and in return gets a commercial license that’s equivalent to the WTFPL. That means CorpA’s contributions are available for CorpB to use, but CorpB has zero obligation to ever contribute a line of code which CorpA could later benefit from. It becomes a battle of money, and Futo Holdings sits as the kingmaker. GPL abates this partially, if CorpA is both using and distributing code. But the Source First License v1.1 has zero mitigation for this, apart from “trust me bro”.

Don’t. OP already said in the previous post that they only need Jellyfin access within their home. The Principle of Least Privilege tilts in favor of keeping Jellyfin off the public Internet. Even if Jellyfin were flawless – and no program is – the only benefit that accrues to OP is that the free tier of ProtonVPN can access Jellyfin.

Opening a large attack surface for such a modest benefit is letting the tail wag the dog. It’s adding a kludge to workaround a different kludge, the latter being ProtonVPN’s very weird paid tier.

Up until the astronaut part, I was fully convinced that this is a law school theoretical question for an inheritance class, because that’s exactly where the vagaries of “is she my sister?” would also arise.

Then again, if we include time dilation due to near-lightspeed travel, we then have to deal with oddball inheritance cases like if your sister dies mid-travel but then you also die. The Uniform Simultaneous Death Act adopted by several US States would only apply if the difference in time-of-death is within 120 hours, but the Act is silent as to which reference plane will be used, especially if your sister is considered to be traveling “internationally” due to being in space, thus not being in the same US state or time zone as you might be in.

So maybe the entire question is a valid inheritance case study after all.

PS: Reddit doesn’t allow edit post titles, needed to repost

But this is Lemmy.

stay in a license that still allows Hashicorp / IBM to benefit from community contributions?

I don’t see how this is the case. As Hashicorp explains, they switched from the open-source Mozilla Public License 2.0 (MPL) to the proprietary Business Source License (BSL) in order to apply restrictions upon users of Terraform:

Organizations providing competitive offerings to HashiCorp will no longer be permitted to use the community edition products free of charge under our BSL license.

The terms of the MPL and BSL are incompatible, insofar that Hashicorp cannot unilaterally relicense MPL code from OpenTofu into BSL code in Terraform. But Hashicorp could still use/incorporate OpenTofu MPL code into Terraform, provided that they honor the rest of the obligations of the MPL.

This is exactly the same situation as what Hashicorp was obliged to do before the licensing kerfuffle, so it cuts against Hashicorp’s objective: why continue developing legacy Terraform if OpenTofu is going to provide continuity? Perhaps they only intend to develop new, exclusive features that build upon the common legacy code, but users would now retain an option to reject those pricy add-ons and just stick with the free, open-source functionality from OpenTofu.

It seems to me less about giving the finger to Hashicorp and more about giving users a choice in the matter. Without OpenTofu, the userbase are forced into the BSL terms of Terraform, where Hashicorp could unilaterally prohibit any production use by yet another license change. That’s no way to live or work, with such a threat hanging overhead. OpenTofu lifts that threat by providing competition, and so maybe does kinda throw the finger at Hashicorp anyway.

On the flip side, precisely because MPL code cannot be unilaterally relicensed to BSL, if OpenTofu starts to gain new features that Terrarform doesn’t have, Hashicorp can incorporate those features but they won’t be unique. Why would a paying customer give money to Hashicorp for something that OpenTofu provides for free? The ecosystem of features cuts both ways.

Finally, it gives Hashicorp an out: if they acquiesce in future, their BSL code can be unilaterally relicensed as MPL once more, thus allowing code sharing with OpenTofu. Had OpenTofu picked a different license, this could have been much harder. But as described in the OpenTofu manifesto, continuity was the goal.

As it happens, this is strikingly similar to an interview question I sometimes ask: what parts of a multitasking OS cannot be written wholly in C. As one might expect, the question is intentionally open-ended so as to query a candidate’s understanding of the capabilities and limitations of the C language. Your question asks about Python, but I posit that some OS requirement which a low-level language like C cannot accomplish would be equally intractable for Python.

Cutting straight to the chase, C is insufficient for initializing the stack pointer. Sure, C itself might not technically require a working stack, but a multitasking operating system written in C must have a stack by the time it starts running user code. So most will do that initialization much earlier, so that the OS’s startup functions can utilize the stack.

Thjs is normally done by the bootloader code, which is typically written in assembly and runs when the CPU is taken out of reset, and then will jump into the OS’s C code. The C functions will allocate local variables on the stack, and everything will work just fine, even rewriting the stack pointer using intrinsics to cause a context switch (although this code is often – but not always – written in assembly too).

The crux of the issue is that the initial value of the stack pointer cannot be set using C code. Some hardware like the Cortex M0 family will initialize the stack pointer register by copying the value from 0x00 in program memory, but that doesn’t change the fact that C cannot set the stack pointer on its own, because invoking a C function may require a working stack in the first place.

In Python, I think it would be much the same: how could Python itself initialize the stack pointer necessary to start running Python code? You would need a hardware mechanism like with the Cortex M0 to overcome this same problem.

The reason the Cortex M0 added that feature is precisely to enable developers to never be forced to write assembly for that architecture. They can if they want to, but the architecture was designed to be developed with C exclusively, including interrupt handlers.

If you have hardware that natively executes Python bytecode, then your OS could work. But for x86 platforms or most other targets, I don’t think an all-Python, no-assembly OS is possible.

I suspect that PG&E’s smart meters might: 1) support an infrared pulse through an LED on the top of the meter, and 2) use a fairly-open protocol for uploading their meter data to the utility, which can be picked up using a Software Defined Radio (SDR).

Open Energy Monitor has a write-up about using the pulse output, where each pulse means a quantity of energy was delivered (eg 1 Watt-hour). So counting 1000 of such pulses would be 1 kWh, and that would be a way to track your energy consumption for any timescale.

What it won’t do is provide instantaneous power (ie kW drawn at this very moment) because the energy must accumulate to the threshold before sending a pulse. For example, a 9 Watt LED bulb that is powered on would only cause a new pulse every 6.7 minutes. But for larger loads, the indication would be very quick; a 5000 W dryer would emit a new pulse after no more than 0.72 seconds.

The other option is decoding the wireless protocol, which people have done using FOSS software. An RTL-SDR receiver is not very expensive, is very popular, and can also be used for other purposes besides monitoring the electric meter. Insofar as USA law is concerned, unencrypted transmissions are fair game to receive and decode. This method also has a wealth of other useful info in the data stream, such as instantaneous wattage in addition to the counter registers.

Unabashed plug for GnuCash. It’s FOSS, double-entry, and capable enough for oddball personal finances or business finance, with all the spreadsheet exporting one might need.

Oh man, I forgot about that! Guess I have to go rewatch it now.

It’s a joke referencing: https://en.wikipedia.org/wiki/PC_LOAD_LETTER

To make sure we’re all on the same page, this proposal involves creating an account with a service provider, then uploading some sort of preexisting, established proof-of-identity (eg passport data page), and then requesting a token against that account. The token is timestamped and non-fungible, so that when the token is presented to an age-restricted website, that website can query the service provider to verify that: 1) the token is still valid, 2) the person associated with the token is at least a certain age.

If I understood that correctly, what you’re describing is an account service combined with an identity service, which could achieve the objectives of a proof-of-age service, but does not minimize privacy complications. And we already have account services of varying degrees and complexity: Google Accounts, OAuth, etc. Basically any service where you log-in, since the point of logging in is to associate to a account, although one person can have multiple accounts. Passing around tokens isn’t strictly necessary since you can just ask the user to prove account ownership by signing into their Google Account, for example. An account service need not necessarily verify age, eg signing in to post a comment on a news article.

Compare this with an identity service like ID.me, which provide records on an individual; there cannot be multiple records for the same live person. This type of service is distinct from an account service, but some accounts are necessarily tied to a single identity, such as online banking. But apart from KYC regulations or filing one’s taxes online, an identity service isn’t required for most day to day activities, and any additional uses pose identify theft concerns.

Proof-of-age – as I understand it from the Australian legislation – does not necessarily demand an identity service be used to satisfy the law, but the question in this Lemmy thread is whether that’s a distinction without a difference. We don’t want to be checking identities if we don’t have to, for privacy and identity theft reasons.

In short, can a person be uniquely, anonymously age-verified online? I suspect not. Your proposal might be reasonable for an identity service, but does not move us further towards a theoretical privacy-centric proof-of-age validation mechanism. If such a mechanism doesn’t exist, then the Australian legislation would be mandating identity checks for subject websites, which then become targets for the holder of those identity records. This would be bad.

Sadly, this type of scheme suffers from: 1) repudiation, and 2) transferability. An ideal system would be non-repudiable, meaning that when a GUID is used, it is unmistakably an action that could only be undertaken by the age-verified person. But a GUID cannot guarantee that, since it’s easy enough for an adult to start selling their valid GUIDs online to the highest bidder en-masse. And being a simple string, it can easily and confidentially be transferred to the buyer, so that no one but those two would know that the transaction actually took place, or which GUID was passed along.

As a general rule, when complex questions arise which might possibly be solved by encryption, it’s fairly safe to assume that expert cryptographers have already looked at the problem and that no easy or obvious solution exists. That’s not to say that cryptographers must never be questioned, but that the field is complicated enough that incomplete answers abound.

IMO, the other comments have it right: there does not exist a general solution to validate age without also compromising anonymity or revealing one’s identity to someone. And that alone is already a privacy compromise.

I’m on mobile so I can’t compile this myself, but can you clarify on what you’re observing? Does “nothing” mean no output to stdout and stderr? Or that you did get an error message but it’s not dispositive as to what libcurl was doing? Presumably the next step would be to validate that the program is executing at all, either with a debugger or printf-style debug statements at all junctures.

Please include as much detail as you can, since this is now more akin to a bug report.

EDIT: wait a sec. What exactly is this example code meant to do? The Pastebin API call suggests that this is meant to upload a payload to the web, not pull it down. But CURLOPT_WRITEFUNCTION is for receiving data from a URI. What is your intention with running this example program?

Unless I’m mistaken, that first example as-written will fetch POST the network resource and then immediately clean up. The fact that CURLOPT_NOPROGRESS is passed means that the typical progress bar for curl in an interactive shell will be suppressed. The comment in the code even says that to make the example do something useful, you’ll have to pass callback pointers, possibly by way of CURLOPT_WRITEFUNCTION or CURLOPT_WRITEDATA.

From the curl_easy_perform() man page:

A network transfer moves data to a peer or from a peer. An application tells libcurl how to receive data by setting the CURLOPT_WRITEFUNCTION and CURLOPT_WRITEDATA options. To tell libcurl what data to send, there are a few more alternatives but two common ones are CURLOPT_READFUNCTION and CURLOPT_POSTFIELDS.

You might also want to ask around at !indiegaming@lemmy.world , since there are gamedevs there who ostensibly have honed their workflows, even if not necessarily FOSS.

On one hand, I’m pleased that C++ is answering the call for what I’ll call “safety as default”, since as The Register and everyone else since pointed out, if safety constructs are “bolted on” like an afterthought, then of course it’s not going to have very high adoption. Contrast this to Rust and its “unsafe” keyword that marks all the places where the minimum safety of the language might not hold.

On the other hand, while this Safe C++ proposal adopts a similar notion of an “unsafe” context, it also adds a “safe” keyword, to specify that a function will conform to compile-time safety checks. But as the proposal readily admits:

Rust’s functions are safe by default. C++’s are unsafe by default.

While the proposal will surely continue to evolve before being implemented, I forsee a similar situation as in C where code that lacked initial const-correctness will struggle to work with newer code and libraries. In this case, it would be the “unsafe” keyword that proliferates everywhere just to call older, unsafe code from newer, safe callers.

Rust has the advantage that there isn’t much/any legacy Rust to upkeep, and that means the volume of unsafe code in Rust proframs is minimal, making them safer overall today. But for Safe C++ code, there’s going to be a lot of unsafe legacy C++ code and that reduces the safety benefit for programs overall, for the time being

Even as this proposal progresses, the question of whether to start rewriting some code anew in Rust remains relevant. But this is still exciting as a new option to raise the bar in memory safety in C++.

I know this is c/programmerhumor but I’ll take a stab at the question. If I may broaden the question to include collectively the set of software engineers, programmers, and (from a mainframe era) operators – but will still use “programmers” for brevity – then we can find examples of all sorts of other roles being taken over by computers or subsumed as part of a different worker’s job description. So it shouldn’t really be surprising that the job of programmer would also be partially offloaded.

The classic example of computer-induced obsolescence is the job of typist, where a large organization would employ staff to operate typewriters to convert hand-written memos into typed documents. Helped by the availability of word processors – no, not the software but a standalone appliance – and then the personal computer, the expectation moved to where knowledge workers have to type their own documents.

If we look to some of the earliest analog computers, built to compute differential equations such as for weather and flow analysis, a small team of people would be needed to operate and interpret the results for the research staff. But nowadays, researchers are expected to crunch their own numbers, possibly aided by a statistics or data analyst expert, but they’re still working in R or Python, as opposed to a dedicated person or team that sets up the analysis program.

In that sense, the job of setting up tasks to run on a computer – that is, the old definition of “programming” the machine – has moved to the users. But alleviating the burden on programmers isn’t always going to be viewed as obsolescence. Otherwise, we’d say that tab-complete is making human-typing obsolete lol

If there were changes in 2020 to 2024 inclusive, then yes, I’d write it as 2020-2024. But if not inclusive, then I’d write 2021-2023.