Ukv

> There’s no use case for system clipboard

There are many things it makes sense to copy/drag-drop between applications. There are cases where you might not need to, but using the system clipboard is still common.

> Meanwhile, open-source, non-Electron, multi-platform software that handles copy-paste via system clipboard exists just fine (VCV Rack comes to mind)

VCV Rack seems to just use GLFW to handle it, but again I'm not claiming these issues are unavoidable or more likely than not to occur. For any given issue with some software, 99% of other software will not have that same issue.

> The aforementioned RawTherapee has no such issues

I don't mean to claim that the mentioned issues are unavoidable or that some piece of software is more likely than not to have these issues, just that when there are OS-specific issues it's this kind of thing I expect. Clipboard handling is pretty much an entirely different implementation on each platform unless you're using something like Electron that already handles it for you, for instance.

smlen would be 0 for both if there are no small numbers, so end result of both is an empty array.

For the first version small_numbers[0] will contain an arbitrary value at the end, and for the second version it happens to contain the last number read, but that address is outside of the 0-length array being returned.

Performance, clipboard behaviour, and file browser persistence seem like fairly typical OS-specific issues. Obviously not great if they're not properly testing macOS, but I don't think it's an "even bigger red flag" for those to be OS-specific.

Grouping close-together changes of the same control for undo sounds probably intentional to me, like how Ctrl+Z in a textbox doesn't go one character at a time, and if I move something with arrow keys I'd expect that to be one "movement" once I stop rather than one per key repeat. Whether it's grouping too aggressively to the point of being recognized as an issue is probably down to personal preference, though I would lean towards agreeing that less grouping would be better.

The big water usage numbers are always from including hydropower (as this report does, mentioned on page 34), so most of the water just continues on into the sea.

> Except that the same shit happens on ubereats/instacart/doordash driver apps where basically everything is self-serve [...]

That the password-reset was self-serve yet made up 80% of calls was Sohcahtoa82's point. Users that only call in unusual/exceptional circumstances can, by their nature, make a small minority of calls despite being the majority of users.

Security scanners won't be "manual in-depth analysis of all new code" or "Just running and seeing it do things", but somewhere in-between - utilizing static analysis/machine learning. It's a cat-and-mouse game, but the attacker adding code that waits X days to run something obfuscated would be another pattern that they could look for.

I think these attackers are unlikely to add a delay in the first place because the chance of their attack being found out before it activates would be too high. They seem to generally work on the assumption that they have a day or so before the package is yanked (e.g: from maintainer noticing their account is compromised) so need to move fast.

Security scans and authors realizing an unauthorized version was pushed will generally happen regardless of whether regular users updated. Even for compromises that are found by users updating, it'd generally be better to reduce the number of people affected with a slow roll-out rather than everyone jumping on at once.

The BGB (German civil code) looks to have similar:

> Section 276(3): The obligor may not be released in advance from liability for intent

> when library provider asks for "do not use any model"

To my understanding the stance was only really communicated after/because of this ticket ("For everyone listening: I added explicit disclosure of how output to stdout has changed"), and probably still isn't something that most downstream users are going to see.

In general I'm not too sure about a project that is using, and has accepted contributions under, a Free software license trying to then restrict what tools you can use. To me that seems largely against the principle of a Free license. You could get contributors' permission to relicense their work to a non-Free license if you wanted to restrict the tools that users of the library can use.

Shutting down operations as Lavabit/Silent Circle did doesn't negate existing contractual obligations. Voluntarily dissolving the company would also involve completing performance of outstanding contracts.

Bankruptcy process already involves identifying and administering the company's assets, so releasing the server software (as-is) to owners of the game could be part of that.

You still can sell X months access, if that's what you plainly state is being bought.

I don't think you could sell "for as long as the developer supports the game" specifically, since that'd be an illusory promise (no actual obligation if the product can be revoked immediately), making the contract unenforceable and the customer entitled to restitution (a refund).

"infinite support" is pretty much just "leave the customer with the product they bought working". There doesn't need to be any ongoing costs.

> There's lots of proprietary middleware in use in online games

If bills like this pass, there'd be financial pressure on middleware providers to allow distribution at end-of-life (or for their component to be easily severed) else they'd lose out on all customers selling games in California/EU/etc.

> much like telling someone "please die"

If you believed the recipient to be susceptible to the instruction and your intention really was to have them commit suicide, I'm not sure you'd get off scot free if they end up doing so. Particularly if you're delivering the instruction in a way that disguises it being just an untrusted external request, making it seem internal (through subliminal messaging?) to bypass the scrutiny that requests from a third party would normally get.

Not that this case is anywhere close in severity.

I feel it wouldn't be too difficult to get a social-media video to look convincing enough even with just a regular camera and monitor, at least after compression (if end users aren't served raw footage directly, and instead trust the attestation of the site).

Would be a fairly weak heuristic, with most social media images/videos already being like that.

Pointing the camera at a screen could potentially evade that.

> You certainly wouldn't want to simulate and measure the actual light levels in real time. You'd use an entirely separate information system in world space to define stealth areas [...]

Issue of readability still applies for manually defined stealth areas. You want to indicate these in-game to the player somehow, and more complex lighting does so less clearly than a sharp cut-off would.

> Additionally, no one is actually forcing anyone to use ray tracing or real time global illumination schemes. These are self-inflicted wounds.

Some of the lighting techniques mentioned (like ambient occlusion) are relatively basic by modern standards - it's not just ray-tracing. While there is a market for games that put readability above all else, there is also a pull for games with some level of visual detail, both externally from reviewers/consumers and internally.

> [...] just got started and stopped coming up with wild excuses about how new, non-mandatory tool features sometimes dont do what we need them to.

Hocking just seems to be discussing the challenge faced ("there would be some learning if we wanted to really use these modern lighting techniques"), not using it as an excuse to stop making games.

Tends to happen as terms become familiar (Phonograph becomes phonograph, Universe becomes universe, Web site becomes website, …) and lowercase-i internet is now recommended by various style guides.

> you are now responsible for [...] there’s no way I’m self hosting my passwords

You don't need to host anything new or take on any patching responsibilities for anything you weren't before. I already had an FTP server, so put it on there. Wherever you already access arbitrary files across devices (you didn't answer what you do for files outside of your filetype-specific subscriptions, but I'd assume you just have iCloud or something) should work fine.

Not that there are zero reasons to use a SaaS password manager, just that I disagree Keepass is somehow insecure or prohibitively technical for regular users. The solution a lot of people already seem to gravitate towards (if not just password reuse) is "passwords.txt on Google Drive".

> Talk to your local security engineer :)

You made the claim - I'm interested to hear why you believe it, because I suspect it's based on a misunderstanding of how KeePass works.

> and think they can just stand up businesses without understanding the domain

Using KeePass is not analogous to standing up a business.

> For other types of files, I have different apps

How many separate services do you have for accessing files across devices, and what do you do for filetypes outside of what they cover?

> And I like having my passwords across all my devices, updating anywhere I am.

That's how it works for me with a passwords.kdbx file on my FTP server (but any cloud storage works). Same for any filetype.

> And for me, it’s just not worth the headache (and security risk) of hosting my own password manager.

What's the security risk? If anything, it's SaaS password managers that seem to semi-regularly get hit with breaches (well, mostly LastPass).

You don't need to host anything for KeePass - just plop the file next to your notes/etc.

Headache seems greater overall if you're juggling a large number of subscriptions, particularly when they start ramping up payment or moving features you rely on to higher tiers.

> > I assume non-technical people ought at least be able to put their KeePass files on DropBox?

> Non-technical people would not do something this complicated. They don’t even have password managers, let alone a setup like this.

Google Drive/iCloud/OneDrive/Dropbox are already used by non-technical users - moreso than SaaS password managers.

> Shoot, even a lot of technical people (like me) wouldn’t bother with this. It’s why I pay for a cloud-based password manager.

What do you do for when you want to access some other type of file across devices, like notes or photos? If you have notes.txt on an FTP server, just put passwords.kdbx alongside it. If you're subscribing to some new service for each individual filetype you want to sync, with nothing for arbitrary files, that seems like considerably more hassle overall to me.

For many games (and software, IoT devices, etc.), persistence/progression is tied to save files on your own device, and any authentication is more to the publisher's benefit of making sure you have an authorized copy - that's where it should be fine to just patch out the authentication check.

Even for games with centralized server-side progression, if you don't want to release the authentication service when you stop running it, then it could still be acceptable to patch out authentication by default and let those running community servers substitute in their own access system (like cracked/leaked unofficial servers already do).

> This legislation might be more persuasive if it were tied to a reasonable time limit, but I don't see anything of that nature in the text. An obligation to support or refund customers that lasts for a fair timespan (ie. preventing rugpulls) is far less onerous than an obligation to release your code to satisfy someone's nostalgia.

Should we be able to read books and watch movies that were released over, say, 20 years ago - or is that just satisfying someone's nostalgia? Maybe you don't think this matters for games, but with DRM it seems other media isn't far behind.

> A lawnmower isn't a piece of software. It's not licensed. There's an expectation it should continue working.

I believe we should be able to have the same expectation of software, at least where not specifically sold as "X months of access".

> If I sell you an IoT lawnmower, and you get 20 years out of it, do I owe you a full refund if I shut down my server?

Ideally, to avoid unnecessary e-waste, you should patch out the requirement or release the server-side code so I can continue using my lawnmower. Buying it off me might also work, if you're offering approximately what I'd get out of having it continue to work, but I'm not sure if that scales well.

> I don't think all the patches are small costs when you factor in licensing

If bills like this pass, middleware providers would need to license under terms that allow distribution at end-of-life, or lose out on all customers selling software in California/EU/etc. Should also help clear obstacles for developers who already want to distribute their server/source code even before this law but are held back from doing so.

> Mandating you need to put out a patch creates a legal obligation that would sit on your books

There's no issue with creating the patch/releasing the server-side software early, just that I assume they'd want to maintain exclusivity to milk profit for as long as possible.

> It was an externality that made consumers sad, not one making products more expensive

If you expend resources to create some media/software/product, then brick that product while customers would've otherwise still extracted value in excess of the patch's resource cost (developer time, not licensing price), then you're on net wasting resources and thus making products in general more expensive.

Issue is that because the cost of patch is borne by the company, whereas they get to ignore the cost to the customers of bricking the products, the latter is often preferred even though it's typically the more expensive option by a significant margin. A bill like this should fix that.

> I think it's a slippery slope to turn that entitlement onto multiplayer games; if not that, then why not all software that you buy?

I believe it should, and that for a lot of software the case is even stronger.

> Everyone should get a full refund when any software EoL's and companies go bankrupt whenever an online product stops being profitable.

If you take someone's money to buy a CAD package, then no longer want to provide some service it relies on (usually just for authentication reasons), then you should release the server software or patch out the authentication check.

> We didn't give HP the option "make your competitors ink work on your printer, give full refunds, support indefinitely, or open up your ink manufacturing line blueprints"

I'd 100% support doing that!

> So do games just have to have a perpetual endowment to fund any shared component costs? This seems like a logical conclusion.

They don't need to keep services running perpetually. strags's objection seemed to be that it could be infeasible to release services like authentication that they're still running, to which I'm saying they don't really need to consider any of this until they stop running it.

> You may bemoan "oh they just don't want to release the auth service", but it functionally shuffles the cost math.

Releasing or patching it out is largely just fulfilling their side of the deal.

If I sell you a lawnmower that depends on some authentication server to start up, then shut down the server the next day (I got your money, why would I keep the cost?), and don't release the server code or a patch to work without it, then would you not say I've scammed you?

The resource cost of everyone I've sold to losing access to their lawnmowers would be far greater than what it'd cost me to release a patch, just that the former is not a cost borne by me if the law allows me to ignore it.

> I'd personally rather the 5% cheaper games than trying to play a multiplayer only game 20 years later wtih 6 people on the server.

Allowing a company to cut people off of their software (large cost) just to save having to push out a patch (small cost) will, on net, result on more expensive products - since on net you're wasting more resources.

Particularly when it comes to authentication checks, this doesn't just apply to multiplayer games. Imagine if this applied to other forms of media (already kind of happening with DRM), like if we couldn't read books from over 20 years ago.

> It's not feasible to open-source all of that, especially given that it may well still be in use for more recent titles

If they're still running their authentication server (for example), then they wouldn't need to release that service.

Patching the game to no longer contact the authentication server would also be acceptable, for services that aren't a core part of the game. It's pretty likely the game already allows this for development/debugging.

If they've accepted money from people to buy the game, and don't want to keep the authentication service running, and don't want to patch the game to no longer require the authentication service, and don't want to refund people, and don't want to release the authentication service so others can run it - I think it's fair for a regulation to force one of those.

If bills like this pass there'd be financial pressure for middleware providers to either license under terms that allow distribution at the game's end-of-life, or allow their middleware to be easily severed while still leaving the game playable - else they'd lose out on all customers selling games in California/EU/etc.

Which is also a nice side effect to reduce intellectual property barriers for developers that do already want to distribute their server or source code.

If the bankruptcy process already involves identifying and administering the company's assets, I feel releasing the server software (as-is) to owners of the game could be part of that.