Hacker Newsnew | past | comments | ask | show | jobs | submit | prirun's commentslogin

Or, like me, who has never been a runner, a heart rate in the 30's can mean that you have heart block, an electrical problem with your heart where beats are gradually spaced further apart and then there is a longish delay before a reset. In a recent 2-week heart monitor test, my longest delay was 3 seconds and I had 4 of these. There are different types of heart block: mine is type 1 Mobitz/Wenckebach. Not really dangerous - I've had it all my life and known about it for ~35 years. It shows up on all of the modern automatic heart/blood pressure machines because the delays cause unusually low readings whereas a nurse checking your pulse may miss it.

My average heart rate on the test was 58, lowest was 21 (for 3 seconds), and highest was 250 (for 6 beats). A few minutes after getting in bed, my heart rate regularly is in the 40s and sometimes low 30s.


I read that Internet Archive keeps 2 copies of all their data. Storj, the decentralized storage service, is currently in Chap 11 bankruptcy, mostly IMO because of incompetent management. They pay their node operators, the guys that actually maintain the hard drive space, $1.35/TB/mo to store data. (However it costs Storj 1.8x that because of erasure coding). They still have way more available capacity going unused, so it's likely they could lower the payout rate even further and have talked about doing that.

Internet Archive could buy Storj, probably for not much, keep 1 copy of their archive on the IA custom server setup they have now, keep the other copy on Storj, and free up half of the IA disk space. Storj automagically uploads data to 54 nodes, any 29 of which can reconstruct the original data (54/29 is where the 1.8 expansion factor occurs).


"Storj, the decentralized storage service, is currently in Chap 11 bankruptcy,"

"Internet Archive could buy Storj"

Insanely convoluted solution that only someone with crypto-brain would ever come up with. You are really suggesting the Internet Archive should buy a bankrupted crypto company so they can store their data? What?


It's more productive to explain why the idea doesn't work, since people can learn from that.

nonsense is not owed a response.

And yet, here you are responding

Yes, and that's a great idea. Chapter 11 protects companies from their creditors. If a suitor comes along offering to buy the company that is in Chapter 11, the creditors can go to the judge and request that the judge allow the purchase to go through as a way of settling the company's debts. It happens all the time.

Why buy the rights to store data on a bunch of random people's hard drives instead of buying a bunch of hard drives? It's just not efficient.

The major problem with the (low) payout on Storj is that 29/54 node requirement is still too high for reliable long-term data retention.

Also, even if you live in the least-expensive electricity places in the world, residentially it will cost you more in electricity to keep those platters spinning 24/7 [than the payout].

----

It is popular in the hobby cryptomining community to replace your under-desk spaceheater with a Monero mining rig (I also do this), and then only run it during wintertime (b/c it is effectively free mining, if you were already going to be running a resistive spaceheater).

Unfortunately, this cryptomining solution doesn't lend itself well to distributed-datastore cryptos because they are offline the majority of the year (i.e. files inaccessible).

----

As a part-time miner since 2012... I really wanted to like Storj, but if you want to get paid to replace your spaceheater at home, mine Monero on surplus CPUs (for reference: new $500 Ryzen798003xd mines at 5.5khashes/s; obsolete i5 still gets 3.8kH/s). Storj is in bankruptcy for fiscal reasons due to its impossible logistics.


How many BTUs or kJs is that?

I have a combined 2800BTUs of Monero heating capability, which is equivalent to a standard US "spaceheater" running on medium heat.

Localized beneath my main office computer desk, this allows me to further reduce heating of my entire domicile.


That’s pretty impressive I’m going to look into it.

For the past several years, this annualizes to about three weeks of free winter heating (via bespoke XMR). I mine solo, but I imagine if you "pooled" it would be similar incomestream (but more reliable). I have had a year of "no winnings," but I persist with the odds to warm myself and the network.

----

Half of my kilohashing runs on obsolete i5 equipment (==free-to-me, minus geektime) – Monero Foundation strives to operate with GPU- & ASIC- –resistance; processors haven't gotten that much faster (in the past decade), and a surplus i5 isn't that much slower than a new $500 Ryzen (~2/3rds hashrate).

Monero's Windows7 client still works (fully supported), so perhaps you now have a use for your dusty-old laptop?

Should you need to upgrade the hard drive (mining currently requires full-blockchain, which is ~300GB and growing), you might as well experience linux (installing UbuntuOS is easy once you've created the USBmedia).

It is definitely not worth purchasing additional equipment, with residential rates, just to mine monero. I like warm toes, and have lots of spare CPU cores.

----

Reminder: this is only "free electricity" if you're offsetting RESISTIVE HEATING (i.e. not a heatpump). To actually reduce your powerbill and save the planet (the smarter choice), you should install a heatpump for wintertime heating.

This isn't a "guaranteed moneymaker," it's to heat your geeky underdesk toes – you are just making a fancier resistive spaceheater, which occassionally pays for itself.


The building is heated by heat pumps my studio is one large room in the building 60’x 30’ 25’ (20m x 10m x 8m). This would be where some oomph is needed.

Honestly, this is a perfect use-case for the old MacPros (2009-2012) – particularly with the dual Xeon configuration [†] – they are notorious for their turboprop fans and exhorbitant powerbills.

You can usually get one for free (or less, "doing them a favor") via social media. I just gave one away (because the receiver had a better use for it than my XMR mining).

Make sure you use fan-boosting software, to keep everything less than 80°C. See you on the network!

[†] A MacPro5,1 with 12 cores will hash at about half the rate of a modern AMD Ryzen7 chip, using twice the electricity – perfect for your localized toe-heater (they also have incredible airflow, with MacFanControl software; in Linux, disconnect the PCI fan [∑] and the four CPU fans will full-blast). GPU is irrelevant for monero-mining (the stock GT120 [or 57X0] is perfect for this).

[∑] it's useless – or you can disconnect CPU_B_BOOST (fan), which is even more useless (but more-difficult/dangerous: do NOT disconnect _A_)... this makes the BIOS full-blast all remaining fans

NB: Newer i5s (mid-2010s) will hash at identical rates, but use much less power [not ideal for this situation] – but they tend to not have great heatsinks so you may have to run less cores.


I have an xserve that could work and the last Mac G5 tower dual processor dual core with multiple graphics card.

Maybe they could start a Archive@Home project for volunteers to donate unused disk space for the greater good.

They do have that. All archives have torrents.

Which means somewhat popular, somewhat larger have backups. Important would be backups for things nobody else is interested in. The ones where one person in 10 years will ask for.

And half those torrents are missing half their files because the torrent generator races with the upload process and often runs on a half completed upload.

This has been a problem for years at this point and they still haven’t fixed it, it’s frankly bizarre.

https://getdweb.net/ is that project.

https://news.ycombinator.com/item?id=29639222

> As noted the Internet Archive is experimenting with filecoin.io and storj.io and is always open to suggestions about how we might do our jobs better, and improve our service. We also host regular meetups (and have hosted summits and a camp) related to the Decentralized Web. See: https://blog.archive.org/tag/dweb/

Inside The Internet Archive's Infrastructure - https://news.ycombinator.com/item?id=46613324 - February 2026 (119 comments)

u/stavros proposed "Elephant" as well, which could be implemented today without Archive.org's explicit assistance.

Elephant system design - https://gist.github.com/skorokithakis/68984ef699437c5129660d... (A distributed, voluntary backup system (high-level design document))

https://news.ycombinator.com/item?id=46637992 (additional context)

(TLDR Every Archive.org item has a torrent, enabling distributed replication and serving of archived items and their contents, Wayback is a bit trickier; you can also ask your local nation state and museum/preservation apparatus to colocate some IA racks, if one is so inclined; The Internet Archive’s entire annual budget ($30M-$40M) covers 200PB storage plus all operations)


I know I'd love to run something like this!

Isn't storj a crypto thing? I don't think they'd want to be involved. I get the sense they are idealists

They are idealists but also like cryptocurrency and decentralization. I recognize that's pretty rare since the late 2010's reputation of various coins and their environmental impact but IA is heavily associated with (and received much money from) FileCoin:

https://ffdweb.org/

(and I am not saying it's bad, or indeed good, just that the usual expectations of being pro- or anti- cryptocurrency or AI don't easily map to things like the Archive)


The Internet Archive can store data in perpetuity for ~$3/GB one time (estimated based on recent AI driven hardware inflation, used to be $2/GB).

https://blog.dshr.org/2026/01/internet-archives-storage.html

https://blog.dshr.org/2021/03/internet-archive-storage.html

https://archive-it.org/vault/


I've used vultr.com for years with no problems. Recently it wouldn't let me login without solving a Google captcha. I tried private windows, etc and ended up having to cancel my Vultr account and ask for a refund. Fortunately I only used them to spin up test VMs and didn't have any production stuff running there.

I refuse to pay a company for service and then be required to identify motorcycles and traffic lights every time I sign in. I went a few rounds with Vultr customer service and they said (paraphrasing) "It's not something we can fix, you have to talk to Google about it". Right... Google forced you to put their captcha on your web site.


CAPTCHA for login should just be outright illegal, especially if it blocks important functionality like closing your account.

I never got a response when I wrote to the FTC, requesting formal guidance as to whether having to disable NoScript (a browser security measure) to complete a CAPTCHA to unsubscribe from email spam satisfies 16 CFR § 316:

"Neither a sender nor any person acting on behalf of a sender may require that any recipient pay any fee, provide any information other than the recipient's electronic mail address and opt-out preferences, or take any other steps except sending a reply electronic mail message or visiting a single Internet Web page"

https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C...

A simple reading says, no. But I guess they don't want to put that in writing.


A few years ago a service for which we had just implemented a scraper for (they had no API, and the customer needed info from 1000s of accounts) added a captcha right after we had implemented the scraper.

We quickly figured out that the server didn't validate the captcha challenge code with Google. It worked for 3 years until they changed the system to send a code via email to validate your login, and limiting you to 1 session at-a-time. Now we have different problems to deal with...


>CAPTCHA for login should just be outright illegal

How do you prevent credential stuffing attacks?

>especially if it blocks important functionality like closing your account.

That just falls under standard tort law, not to mention recent "click to cancel" legislation some states have been introducing.


> How do you prevent credential stuffing attacks?

CAPTCHAs don't work anymore, at this point. AI can trivially solve them.

Rate-limit the number of attempts, test accounts against known-password lists like HIBP, and support 2FA.


>CAPTCHAs don't work anymore, at this point. AI can trivially solve them.

The point is to raise the cost, not to create some impenetrable barrier. A $5 vps can make hundreds of requests per second. IP bans and rate limiting forces people to use residential proxies, which are like $5/GB. That's much more expensive, but still cheap. Not sure about the token cost of AI is like, but captcha solving service used to charge around $0.002 per solve, which increases costs even more.


There is no raised cost anymore. Every professional doing this work has perfect alignment with regular consumer heuristics.

OS, browser, fingerprinting, networked bytes, residential address spaces.

All of it is done.


For credential stuffing you need only one attempt.

No, it's a numbers game on both sides. Attackers are after hundreds or thousands of accounts, not just one. Defenders knows that exactly 0 hacks are impossible to achieve, and they're just trying to limit losses from fraud, but also costs from anti-fraud.

They have so many accounts broken daily? Then credential stuffing attacks are not prevented.

Then you don't need to automate it, and you can just manually solve the captcha and log in.

Passkey only. No passwords no usernames just passkey

I'm not giving up recovery codes, nor my ability to default to locking out people who physically have my device. I usually don't allow auto-login or biometrics login either.

If a website/app goes passkey only (or, even worse, if it starts relying only on one-time email codes), I won't use it.

I know plenty of others who feel the same, though I don't know if we're numerous enough to put a dent in a company's bottom line or not. I imagine it depends on the company and its target audience.


Two passkeys. If you lose two then yeah, you are boned don't do that. They are absolutely the superior solution

At the minimum, stop using goddamn email addresses for the login.

>How do you prevent credential stuffing attacks?

Passkeys or magic links seem like the way forward here.


Please don't. I find such services obnoxious, especially when they aggressively log you back out. Chasing down a link in your email is much slower than having your password manager fill in the long unique random password and hitting "log in".

>Chasing down a link in your email is much slower than having your password manager fill in the long unique random password and hitting "log in".

That's basically a passkey without its special API.


You can also randomly generate a password for the user on the form they'd normally type one in on registration. Add a "Regen" button to give users more visceral control over it before they submit the form.

That's essentially the same as magic links because most users won't remember/save that password and will have to rely on the usually email-based reset flow.

Sure, but this subset of user was going to otherwise reuse their password and be susceptible to cred-stuffing.

The point is to stop the attack and prevent users from accidentally hosing themselves.


Isn't that essentially a manual passkey?

Passwordless and passkeys. There are no credentials to stuff. Login with magic link, email OTP, passkey, etc. Get rid of the password, rate limit what remains.

Email OTP is garbage without the option to also add a password. That just outsources the problem to the user's email service, and assures that compromising the email inbox alone is enough to immediately also compromise every service that uses passwordless, 2FA-less "magic link" or OTP login.

Email services don't even support true 2FA; many claim to, and ask for a 2FA code for web login, but connecting an email account to a client via POP or IMAP bypasses that.


I implement customer identity and access management for millions of users in financial services, based on requirements driven in part by US federal regulatory and cyber insurance requirements. What’s your experience?

> Email services don't even support true 2FA; many claim to, and ask for a 2FA code for web login, but connecting an email account to a client via POP or IMAP bypasses that.

"In less than a year, passkeys have been used to authenticate people more than 1 billion times across over 400 million Google Accounts. Passkeys are easy to use and phishing resistant, only relying on a fingerprint, face scan or a pin making them 50% faster than passwords. In fact, on a daily basis passkeys are already used for authentication on Google Accounts more often than legacy forms of 2SV, such as SMS one-time passwords (OTPs) and app based OTPs (such as Authenticator apps) combined."

https://blog.google/innovation-and-ai/technology/safety-secu... (April 2024)

Don't forget: Microsoft is killing passwords. How to set up a Microsoft passkey before August deadline. - https://mashable.com/article/microsoft-passkey-how-to-passwo... - June 20th, 2025

(All major email providers support either passkeys, or in the case of Microsoft, passwordless ["strong authentication"]; we can consider the user creating an app specific secret for an external mail client minimal risk if performed after strong authentication has occurred, as the odds are low of that secret being phished or exfiltrated once configured in their mail client of choice, for the few folks interested in such a user experience with web based email services)


But passkeys are not supported natively (i.e. without a USB key or other shenanigans) by Firefox on Linux, as there is no place to store them. I do have a USB key, but it's annoying enough that I don't like passkeys if I can avoid them (instead using long randomly-generated passwords by Firefox's builtin-in password manager).

Maybe Lennart needs to write systemd-passkeyd .


I admit this is a gap, but this use case is a rounding error at the scale of users and daily logins. If someone wants to fix this, drop a link to sponsor the time and tokens needed to enable native support. Does a Yubikey or secure authenticator work for your use cases currently?

Yes, a yubikey works for when I really need it, but it's enough friction to take out out and plug in that it's just annoying enough.

I'll talk to some industry folks and see what we can do.

Rate limiting

Attacks have been distributed for quite some time if your service has any loot worth attacking. You have to handle the case where every request comes from a unique IP address.

Maybe if the number of failed logins per hour grows by 10000%

Ok, debian forky, 155.0.1, successfully logged into vultr.com after a year inactive, added a credit card and a little credit. I do, however, still stupidly use google authenticator for 2FA. The captcha was just a checkbox.

That said I have run into a number of unsolvable captchas lately on firefox. Had to use chromium on a healthcorp insurer site.


I don't mind a checkbox. I don't even mind the "proof of work" types that take 10 seconds extra. But identifying traffic-y things over and over is way too much for me. I did do one screen, thinking it would let me in, but it just gave me another.

I do use Firefox. And I couldn't cancel my account myself: had to request it via email since I couldn't login. They were good about doing it right away and said they issued a refund for the balance.


The captcha is not just a checkbox, it's recaptcha.

I've had this for a few months trying to log into https://console.vultr.com/...

It does it for me if I use a VPN (Mullvad) - if I don't use a VPN then I haven't noticed I get them.

But yeah, very annoying.


Most captchas are invisible as long as they like your IP and device. But they still do the fingerprinting in the background.

> its culture is not very collaborative.

Second this. Their BDFL's personality is not suited for the job IMHO.

Example: Nim's hash table data structures (Python dict, Go map) are called tables. There are several variants of these, including OrderedTable. Deleting a key from an OrderedTable had O(n) performance because Nim built an entirely new OrderedTable, filtering out the key to be deleted. There were a couple of reasons for this:

- the internal list that preserved element order was only forward threaded, making an O(1) delete impossible

- Nim tables allowed the same key to be inserted multiple times, each with different values. I thought this was a bit crazy compared to other languages.

I tried to changed OrderedTable to use a doubly-linked list to allow O(1) deletes, and to get the multiple key feature removed.

What I didn't realize is that Araq, the BDFL, used ordered tables a lot in the Nim compiler, used the multiple value feature, and didn't want to add the memory overhead of a 2nd list to OrderedTable. His main reason was "deletes don't happen too often". At that point it became impossible to convince him that for a hash table to have O(n) delete performance was ridiculous and would be unexpected for anyone using OrderedTable. I gave up, left, and haven't been back.


Andreas is simultaneously brilliant and myopic to needs outside of his own (compiler dev).

It's amazing how many fights he gets into with Status-IM engineers who are the biggest financial supporters of the project and the only noteworthy company that heavily uses Nim.

Has OrderedTable been ported to Nimony? Does it still have this bug?


OrderedTable in Nim appears to be the same and still have O(n) performance. On a delete, an entirely new table is constructed.

https://github.com/nim-lang/Nim/blob/devel/lib/pure/collecti...

I didn't know about Nimony and just took a look.

https://github.com/nim-lang/nimony/blob/master/lib/std/table...

OrderedTable is now a synonym for Table, ie, both are ordered. To delete a key, the key is looked up to get an index position x in a Seq, the Seq entries after x are shifted left, the Seq is trimmed of the last element, and then the entire table is rehashed because shifting the Seq invalidates the previous hash codes. The performance is better than Nim OrderedTables because at least an entirely new table isn't created, and it probably works fine for small tables, but it still isn't O(1). The performance would be similar to removing an item from a single-threaded sorted list: most painful to remove the 1st element, least painful to remove the last element, but then you still have to rehash the entire table.


I just asked Google AI how LLMs translate COBOL code containing GOTOs into Java, a language that doesn't have GOTO. It gave several examples, one of them being this:

COBOL code:

  PROCESS-DATA.
      ADD 1 TO COUNTER.
      DISPLAY COUNTER.
      IF COUNTER < 10 GO TO PROCESS-DATA.
Java translation:

  while (counter < 10) {
    counter++;
    System.out.println(counter);
  }
If "counter" is 10 on entry, the COBOL code prints 11 while the Java code prints nothing. So not only keeping old bugs, but apparently introducing new ones too!

I wrote COBOL code for a few years at a job when I was a teenager. What makes legacy COBOL code difficult IMO is it can sometimes be very hard to maintain a mental execution state when examining the code, for several reasons:

1. all variables are global, aka, WORKING-STORAGE. You list all the variables used in the program and they are accessible to the entire program.

2. programs are divided into paragraphs. Control normally flows sequentially top to bottom through paragraphs, one executing after another. Except that the PERFORM statement can drastically alter this normal flow control, and you can't tell by looking at a paragraph how it will be executed. To do that, you have to look at all PERFORM statements that mention this paragraph or any paragraph physically before it, because in COBOL you can say PERFORM PARA1 THROUGH PARA27. If PARA13 is physically between PARA1 and PARA27, it's potentially going to get executed.

3. In true legacy COBOL, before structured COBOL was a thing (circa 1985), the main control flow statement in addition to PERFORM was GOTO. Lots of flag setting, and lots of GOTOs. So in the previous example, you can't tell if PARA13 is going to get executed because any prior statement might be a GOTO PARA14, skipping execution of PARA13. But even worse, you are still under the influence of the PERFORM THRU, so after PARA27 is executed, control returns to the statement following the PERFORM THRU, wherever that was. But if you GOTO PARA27, without being under a PERFORM THRU, then PARA27 is executed followed by the next sequential paragraph. Trying to figure this out statically by looking at the program can be very difficult, especially considering PERFORMs that are nested at runtime but may not be anywhere near each other in a code listing.


Isn't this exactly what every mobile app does when the db is on a phone, and every app where the db is kept on the local machine? I do it with HashBackup and have done 35 db migrations over 17 years without much trouble. There have been 1 or 2 migrations that had a bug, but you fix that by doing another migration.


SQLite has transactional DDL: you can start a transaction, do a bunch of create tables, copy data from old tables into the new tables. If an error occurs during this and a rollback occurs, everything will be just like it was before the transaction started. If a commit occurs, the migration succeeds and everyone sees the new schema on their next transaction.

In rollback mode, only the migration thread can be active because it's a write transaction, but I'm guessing in WAL mode, readers can continue to read during the migration, as with any other write transaction. I don't use WAL mode much because for my application (HashBackup), I don't need db concurrency.


If you can accept downtime and you really don't need db concurrency, then that's great and SQLite is probably a good fit for you. There are many applications for which that isn't the case.


My sister uses Windows 10 in her one-person accounting business. The performance of everything she does is fine as is. The main thing she needs is stability, and the last thing she wants is any kind of upheaval of her computing environment, the processes she uses every day, the software she uses every day, etc. She has all kinds of workarounds for flaky software she has to use every day, and figuring out new workarounds for new flaky software is not something she wants at all.

Microsoft would do much better IMO if it focused on reducing problems and increasing their ability to support users rather than adding features and constantly changing the way people have to interact with their computer. A lot of people simply don't care about that crap.


Seems to me the purpose of all these releases, credits, pricing changes, harness changes, unpredictable token usages for the same task, etc. is to keep customers completely befuddled so that it's impossible to compare AI products. It's like hiring a consultant who sends invoices every month that aren't related to hours worked or project progress, but are whatever the consultant feels like billing, and you're expected to keep quiet and and keep paying.


It's a new and improved version of an existing model? I don't think it's intentionally befuddling.


I compare online marketplaces to ISPs: we don't expect ISPs to filter the traffic going over their network to make sure it complies with all laws, because that would be impossible. Having actually run a marketplace in a previous life, it's a similar situation. How is a marketplace with millions of products supposed to vet each individual product? About the only thing a marketplace can do is provide some kind of customer feedback mechanism, make sure customers can get refunds easily and quickly, and kick off merchants and buyers that have too many complaints (though they will probably just register again under a different name).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: