51–60 of 93 posts
Cryptobros telling you never to use an exchange due to FTX and other examples, also its super easy to use...
What stupidity
Earlier quoted context omitted.
Has it died? I am getting mixed signals. For example, the Javascript Jabber podcast, which targets front-end web developers in general, ran an episode with some sort of introduction to web3 (and not in the negative sense) just two months ago [0]. 0 - https://topenddevs.com/podcasts/javascript-jabber/episodes/w...
> Has it died? Yes. All the web3 influencers are on AI now.
This is your reminder that every crypto"currency" using a transaction fee is fundamentally a scam and everything that is happening using them is merely hype to get you involved in them.
I'm all for bashing crypto bros, but really? The fundamental benefit of crypto currencies is being independent of central authorities. Do you think it has failed in that regard?
This is your reminder that every crypto"currency" using a transaction fee is fundamentally a scam and everything that is happening using them is merely hype to get you involved in them.
That's a bit like saying that every public toilet that charges a fee is a scam. Surely there are scams and hype in this industry. Fees are for inclusion of a transaction in a block. And some pretty clever game theory was implemented as part of eip1559 in Ethereum to make fees efficient and fair.
Genuine question here: isn’t it a standard security practice to avoid committing keys (or other secrets) to repos? Edit: and what’s the best practice here? Is it using a key management system of some sort? (I’m thinking of scenarios where you might need to deploy your code + secrets on a remote server, say to authenticate with a third party API)
There are a variety of options, depending on what type of software you're developing, how much you're willing to be locked into third party tools, and things like that.
The simplest is to just save the credentials somewhere like the user's home directory, outside of the git repo. This is what a lot of command line tools do.
Environment variables are also a popular option - most CI build systems will let you store 'secrets' that are passed into the build process as environment variables.
Larger scale projects will often end up with a configuration management mechanism, enabling 'configuration as code'. When doing this it will often be interlinked with credential management. After all, why not store the hostname of the database alongside the username and password?
If you're in a cloud environment, they will have 'instance metadata' that can (with configuration) pass cloud provider credentials into your instance. They will often provide a secret store service you can access using those credentials, and will let you authenticate to databases and blob stores and whatnot using those credentials so long as you stay within their cloud ecosystem.
Large corporations like 'credential rotation' where secrets get revoked and re-issued on a regular basis. The cloud environment can do this between your instance and their provided services - or you can do it yourself in an ad-hoc way.
All the major PC operating systems provide a secret storage function or 'keyring' although it's debatable whether it's all that different to just saving a file on disk. It used to be, back before the rise of full disk encryption though.
And of course if you're writing a mobile app, the operating system is a lot more locked down. So there you can store credentials in the system keyring and other applications can't access them.
Genuine question here: isn’t it a standard security practice to avoid committing keys (or other secrets) to repos? Edit: and what’s the best practice here? Is it using a key management system of some sort? (I’m thinking of scenarios where you might need to deploy your code + secrets on a remote server, say to authenticate with a third party API)
It is standard security practice to try to avoid committing keys, yes. Unless it's to a private repo you know will never be made public. There are a variety of options, depending on what type of software you're developing, how much you're willing to be locked into third party tools, and things like that. The simplest is to just save the credentials somewhere like the user's home directory, outside of the git repo. Th…
> Web3 We’re still doing that?
Has it died? I am getting mixed signals. For example, the Javascript Jabber podcast, which targets front-end web developers in general, ran an episode with some sort of introduction to web3 (and not in the negative sense) just two months ago [0]. 0 - https://topenddevs.com/podcasts/javascript-jabber/episodes/w...
Nope! It's going great[1]!
> In 2023, Guan posted his opinion on smart contract engineers. According to Guan, projects that pay smart contract engineers $200,000 are “ngmi,” which is short for “not gonna make it.” The Web3 founder said that any solid developer “should be able to write solidity with the help of ChatGPT.” Ah, schadenfreude.
Earlier quoted context omitted.
An EMP taking out the entire world power grid would be a complete disaster for everyone. Goldbugs and people with cash in their mattresses included.
Money is a key part of the formation of societies and history shows that many independent civilisations came up with money time and time again. Gold is a great form of money thanks to its unique chemistry: Its colour and lustre is unique - it's fairly easy to tell something is gold-ish by eye and weight. This is why gold was chosen by our low-tech forebears. Its lower melting temp makes it easier to purify than say P…
Genuine question here: isn’t it a standard security practice to avoid committing keys (or other secrets) to repos? Edit: and what’s the best practice here? Is it using a key management system of some sort? (I’m thinking of scenarios where you might need to deploy your code + secrets on a remote server, say to authenticate with a third party API)
It is standard security practice to try to avoid committing keys, yes. Unless it's to a private repo you know will never be made public. There are a variety of options, depending on what type of software you're developing, how much you're willing to be locked into third party tools, and things like that. The simplest is to just save the credentials somewhere like the user's home directory, outside of the git repo. Th…
Not even then and this is why