Arrowmaster

> Why does a hill billy who insists on living at the bottom of the Grand Canyon deserve a subsidy?

I'm going to say this nicely once instead of the reply I really wanted to say because I'll give you the benefit of the doubt of not knowing or looking it up.

Because it provides postal service to the Havasupai people living on their native land at the bottom of the Grand Canyon. Would you like to take a guess as to why Supai, Arizona, the capital of the Havasupai Nation, is located at the bottom of the Grand Canyon.

USPS as a public entity of the US government is required to deliver mail to all addresses. I don't know all the specific details and I'm sure there's some exceptions for getting service to a new location but existing locations cannot be removed.

There is daily USPS service to a postbox at the bottom of the Grand Canyon that is only accessible by mule paths. I guarantee this service would either be cancelled or go up in cost to thousands of dollars per letter if USPS was privatized. The sheer size and remoteness of parts of the USA is why it's a public good.

https://facts.usps.com/8-mile-mule-train-delivery/

This entire scheme is devoid of a working knowledge of how anything works. I'm wondering what the rug pull is going to be. Crypto or VC?

Yes. I think autocorrect got me on mobile keyboard.

As things are right now, I see this as a respectable way of operating.

Michael has made his views and usage of AI known. The Ghostty project has a detailed AI policy for users to see and the team is willing to devote resources to enforcing a middle ground policy. The Zig project has a detailed policy taking a strict stance and as a result I expect they do not have expend as much resources when a contribution is suspected of being AI assisted.

A strict policy on either side is easier to enforce based on finite resources (mostly people). I'm sure many projects would like to have a middle ground policy but cannot currently devote the resources it would require long term. We might never see a shift in moderation abilities and this remains for the longer term, or there could be advanced in moderation that allows projects to adopt a more nuisanced policy that's right for them.

No it's not. It might vary by country and culture but in the west that amount has consistently been found to be well over the poverty line and more often over double the median household income.

> The author mentions avoiding multiple logins and searching across forges. The former is already addressed by social logins / federated identity. The latter is not very useful today, on a centralized GitHub, aside from finding leaked credentials and vulnerable code.

Absolutely not. Social logins are unacceptable and I refuse to use sites that depend on them and do not provide a normal method to make an account.

Ideally projects like this can bring us a model where you don't need to login to some other forge to interact with a project but do it by forking it onto your own forge and submitting pull requests between forges.

SteamOS is not designed or meant for installation as a generic OS. It is only designed to run on the specific supported hardware devices that it comes preinstalled on.

No matter how many times you see LTT install it on a system they have assembled, its not supposed to be used that way and not supported.

You can expect it to not work. SteamOS is not designed or meant for installation as a generic OS. It is only designed to run on the specific supported hardware devices that it comes preinstalled on.

No matter how many times you see LTT install it on a system they have assembled, its not supposed to be used that way and not supported.

At least the signal one is using the new DEB822 format, but whomever wrote that missed the fact they could have just embedded the key into the sources file and it would be a very simple command.

I'm fairly sure both of those are available from extrepo making them a single short command away. https://manpages.debian.org/trixie/extrepo/extrepo.1p.en.htm...

It's not in Debian 13, the package was flagged with a critical bug and was not fixed prior to release.

This has been their policy but now it's more explicitly defined. Go look through the submissions on https://github.com/flathub/flathub/pulls?q=is%3Apr to understand how bad the problem they are dealing with is.

I went back and checked. It was not Plaid but Trustly. I've never heard of either before but Trustly's name makes me want to trust it even less than Plaid. And I'm more concerned about all of my personal information such as my transaction history for the past 90 days being siphoned up by yet another commercial entity that can probably profit more from it than the transaction fee they would have collected.

That blog post is a perfect example of when RFC5737 should be used.

https://datatracker.ietf.org/doc/rfc5737/

Yesterday I was renewing my vehicle registration through my US states website. They offered a range of payment options using embedded options on the site. The direct bank account option had the lowest fee but when I tried it I was immediately scared of the security. They used a 3rd party bank account transfer provider that asked me what bank I used and looked like it was going to prompt me for my login info before it errored out and I moved on.

Why can't the US have sane banking standards instead of this mess where you have to agree to a new 3rd party TOS and EULA for every purchase you want to make.

What products? Cisco hasn't built a product in decades, they only acquire companies and throw their name in front of the existing product. Do they mean they will only be purchasing AI built products by the end of 2027?

If they MITMed the console then they have probably MITMed the entire deployment process and now have the one time use key already.

What exactly are you talking about? Those don't seem related.

20 some years ago when cable broadband was new, you connected a computer and got public IP. For this example let's just assume it was a public/24. Back then there was no firewall built into Windows, it didn't ask you if you were connecting to a public or private network.

For some ISPs you could connect a switch or hub (they still existed with cable came out, 1gbps switches were expensive) and connect multiple computers and they would all get different public IPs.

Back then a lot of network applications like windows filesharing heavily used the local subnet broadcast IP to announce themselves to other local computers on the network. Yes this meant when you opened up windows file sharing you might see the share from Dave's computer across town. I don't recall if the hidden always on shares like $c where widely know about at this time.

ISPs fixed this by blocking most of the traffic to and from the subnet broadcast address at the modem/headend level but for some time after I could still run a packet capture and see all the ARP packets and some other broadcasts from other models on my node, but it wasn't enough to be able to interfere with them anymore.

Yes. Every clone of this idea does the same thing and a new one pops up every week. When I try to point out that the secrets should be exposed through file namespaces instead of ENV vars, the amount of hostility is shocking.

Honestly I was expecting more. There are many languages that support Unicode in variable or function names and I expected it to be used there.

It sounds like Python only allows approved Unicode characters to start a variable name but if it allowed any you could do something like `nonprintable = lambda x: insert exploit code here`. If that was hidden in what looked like a blank line between other additions would you catch it?

I'm sure there's some other language out there that has similar syntax and lax Unicode rules this could be used in.

The solution is that this and many other Unicode formatting characters should be ignored and converted to a visible indicator in all code views when you expect plain text.

You know that QR code is just text you can read right? It's just an otpauth:// URI you can copy and paste into most password managers.

We even have these amazing things that securely share passwords or other secret data between multiple authorized users.

Seriously just scan the QR code and put it in any password manager that supports TOTP and it will start outputing codes.

The latest release was June 2022 and the last non dependabot commit was March 2023, until new activity 4 days ago using AI. Why should anyone use this?

Part of how the USA got that way is hilariously enough, anti-corruption policies.

Disagree, the best way to pass secrets is by using mount namespaces (systemd and docker do this under /run/secrets/) so that the can program can access the secrets as needed but they don't exist in the environment. The process is not complicated, many system already implement it. By keeping them out of ENV variables you no longer have to worry about the entire ENV getting written out during a crash or debugging and exposing the secrets.

I'm currently in the endless email loop because someone named Raymond used one of my Gmail names to register with State Farm. One of their agents even emails me directly when he gets really behind on his payments but won't do anything when I tell them it's the wrong email.

In the past when this happens I usually reset the password and change the email to some anon throwaway but I can't do that without Raymonds DOB (don't quote me on that, been a while since I tried).

Not just idiots, rich idiots that will make more from the hype and publicity than we normal people could make in a few years.

This would be perfect if it also was able to expose secrets as files scoped to the process ala /run/secrets/secret_name.

The problem isn't the .env file itself but using environment variables at all to pass secrets is insecure.

While this is a good feature, I fear most people aren't aware of git archive. Of the more basic CI tools I have looked at, I didn't notice any of them using git archive. Capistrano is the first I now know of that does this. Are there any others?

There is also export-subst that is also used by git archive to create an output similar to git describe directly in a file.