HN user
I wish that Opera Omnia, also by Stephen Lavelle, got more attention. It is mind-blowing exploration of the idea of propaganda and revisionist history, which somehow also manages to be engaging and fun, with an incredibly unique core mechanic.
It would be hilarious if people wound up snorting or boofing their GLP-1s (≧▽≦)
The best example of managing expectations of all time is in the Time Zone Database documentation:
The tz database predicts future timestamps, and current predictions will be incorrect after future governments change the rules.
General-purpose deduplication sounds good in theory but tends not to work out in practice. IPFS uses a rolling hash with variable-sized pieces, in an attempt to deduplicate data rysnc-style. However, in practice, it doesn't actually make a difference, and adds complexity for no reason.
This is stupid good advice. I use quicksilver as a launcher, and by putting bookmarks in a folder, I can index them and launch them like any other app or document on disk. Thanks for writing this up!
I definitely don't think Just will ever unseat Make. Just doesn't have file-based dependencies, so it's not a build system, just a command runner.
As far as unseating Make as a command runner, I think that might just take Just being available in more places, since one of the main advantages of Make that many users cite is that it's available everywhere. Just is already available in a lot of package repos, but not all of them. Finally packaging Just for Debian[0] would help a lot.
This is the canonical video on the subject: https://www.youtube.com/watch?v=TmVMh-nT200
One time me and a friend having an animated conversation on the 7th floor of Soda hall at Berkeley and William Kahan came out and gave us a coupon for Sizzlers. I think that was his way of telling us to get the fuck out.
It's usually actually bread baking, not painting, in my experience.
Misread the title as "Which John von Neumann Died at Los Alamos?" and now I really want to read that article.
Don't let the article put you off, the paper, no paywall, is much better and much more concrete:
https://academic.oup.com/ajcn/advance-article/doi/10.1093/aj...
The fact that consumers don't want phones with 7 years of guaranteed updates (if they did, they would be willing to pay more for them, and smartphone makers would happily oblige) means that the impact on resale values would likely be small, or that consumers are unlikely to try to resell their phones.
If this law comes into effect, consumers will pay the increased cost of delivery of 7 years of software updates when they purchase new phones.
Smartphone makers don't sell new phones with a higher price tag and the guarantee of 7 years of software updates, likely because consumers would prefer a lower price and no guarantee.
Thus, the law would effectively force people to buy something that they don't want.
The post doesn't seem to offer any evidence for its claim.
Fortunately, if you're feeling entrepreneurial, you can spin up an Agora* instance and start selling whatever you want for Lightning Payments.
You bet!
These are definitely not dumb questions!
Liquidity management is one of the most complicated aspects of the Lightning Network, and certainly one of the most counter-intuitive.
The basic primitive that makes up the Lightning Network is a "channel". A channel is between two nodes, has a fixed capacity, is opened by making a on-chain Bitcoin transaction, and is closed by making an on-chain Bitcoin transaction.
While the channel is open, the two parties to the channel can make payments between themselves, but do not have to publish a Bitcoin transaction for each one of these payments. They only have to publish a Bitcoin transaction when they want to close the channel, which nets-out the intermediate transactions made since it was opened.
As a concrete example, let's say Alice and Bob open a channel, with Alice contributing 1 BTC when the channel is opened, and Bob contributing 0 BTC. Initially, their balances on the channel are:
Alice: 1 BTC
Bob: 0 BTC
Alice: 0.9 BTC
Bob: 0.1 BTC
However, at the very beginning, when Bob's balance was 0 BTC, he could not have sent money to Alice. Due to a lack of inbound liquidity, which is, quite simply, money on the other side of a channel, which can be sent to you.
This is an aspect of the Lightning Network that is very different from other payment systems, and from on-chain Bitcoin payments. You must arrange to have sufficient inbound liquidity to receive payments.
You ask a good question: What if I just want to assume that the customer is good for the money and queue it up myself for settlement once I have the liquidity to spare?
Let's imagine that we were in the initial state, Alice had 1 BTC in the channel, Bob 0 BTC, and Alice let Bob make a payment to her of 1 BTC. The new balance would be:
Alice: 2 BTC
Bob: -1 BTC
If you're using htlc.me, that's probably the issue. htlc.me is a testnet wallet, so it can only pay testnet invoices, and agora.download is on mainnet.
Just saw this now, but agora.download is on mainnnet, and test.agora.download is on testnet, so if you're using a testnet wallet, it won't be able to pay the mainnet invoices from agora.download.
Can you explain why it will be an issue for anyone who hosts it? The host determines what content is available. Agora does not yet support user uploads.
The possibility of losing funds exists, but bugs are something you would expect with any in-development technology. And, existing payment services are not without risk. Getting your account frozen and funds taken is pretty common with PayPal, Square, and other payment providers, which is not possible with the Lightning Network.
Definitely!
It's actually pretty easy to get into and out of Bitcoin. river.com, is a US-based service that allows buying and selling bitcoin with USD, making USD transfers to and from a linked bank account, and making and receiving Lightning Network payments.
So you could set up an LND instance, get inbound liquidity with a service like Bitrefill*, and then withdraw any funds via the Lightning Network to a River account, sell the proceeds for USD, and transfer them to your bank account.
I use River as an example because it's my favorite, but there are many other services that you could also use.
* It's slightly subtle aspect of the Lightning Network, but in order to receive funds, you need inbound liquidity, i.e. a channel with your Lightning Network node with funds on your counterparty's side of the channel. This can be accomplished buy buying inbound liquidity from a service like Bitrefill: https://www.bitrefill.com/buy/lightning-channel/
It's definitely challenging to set up an LND instance. I'll try to find a good one and link to it from our readme!
Ahh, not quite. I thought you were asking about a wallet for making payments, i.e. for buying content from Agora.
In order to process payments for your Agora instance, you would need to connect it to an LND instance that you ran yourself.
If you connected an Agora instance to an LND instance, you would have to trust the person who ran that instance, since they would be in control of funds from payments, so I think the best idea is to run your own LND instance.
We have tested it using real BTC, so far so good! LND is definitely still in beta, and the Lightning Network itself is still in its infancy, so it's a good idea not to have too much funds in an LND wallet.
We're try to be very careful when developing Agora, and all features are covered by unit and integration tests. However, bugs are always a possibility.
Thank you for the kind words!
The most convenient Lightning Wallet is probably Wallet of Satoshi, which you can find on the Apple or Android app stores. Once you download it, you can fund it with an on-chain transaction. Once you have funds in the wallet, you should be able to pay for invoices at agora.download.
Are you using the agora.download or test.agora.download? If you're using test.agora.download, are you paying with htlc.me? Can you provide the invoice ID? (It's the hexadecimal string after `/invoice/`.)