Your water in the desert costing 100 times what it costs where it rains is meant to represent its scarcity here vs over there.
Take cuban dollars vs normal dollar. In there the two tenders aren't proxy for value. Proxy for a political control so that the wealthy visitor pays 10 times, for the same bottle of water on the same shelf.
You're describing gouging and gold rush pricing, which thankfully not a feature any major economic system relies on for everyday operation.
It's entirely reasonable to expect logistical costs to inflate the price of a good, so the price should reflect the market equilibrium value of the service of bringing water into the middle of the desert, not the good.
We are hoarding money to buy many bottles. The chinese are making and filling it while drilling wells that dont seem financally viable. They spoiled their entire bottle buying budget on that? What dumb communist central planners.
EDIT: Sorry... that is too strong... "state aligned influence media". Note that the headline might be true, or it might not, but that source is quite glowy.
In Australia, an SDE + overhead costs say $1500 / work day, so 4 engineers for a month is about $100k. The money has to be allocated from budgets and planned for etc. Dev effort affects the financial viability and competitiveness of projects.
I feel like many employees have a kind of blind spot around this? Like for most other situations, money is a thing to be thought about and carefully accounted for, BUT in the specific case where it's their own days of effort, those don't feel like money.
Also, the software itself presumably has some impact or outcome and quite often dates can matter for that. Especially if there are external commitments.
The only approach that genuinely works for software development is to treat it as a "bet". There are never any guarantees in software development.
1. Think about what product/system you want built.
2. Think about how much you're willing to invest to get it (time and money).
3. Cap your time and money spend based on (2).
4. Let the team start building and demo progress regularly to get a sense of whether they'll actually be able to deliver a good enough version of (1) within time/budget.
If it's not going well, kill the project (there needs to be some provision in the contract/agreement/etc. for this). If it's going well, keep it going.
The exact same way you'd treat any other investment decision.
In the real world, if you've got $100k, you could choose to invest all of it into project A, or all into project B, or perhaps start both and kill whichever one isn't looking promising.
You'd need to weigh that against the potential returns you'd get from investing all or part of that money into equities, bonds, or just keeping it in cash.
You mean… by making a forward-looking estimates of cost, time-to-value, return? (even if it's implicit, not documented, vibes-based?).
When devs refuse to estimate, it just pushes the estimating up the org chart. Execs still have to commit resources and do sequencing. They’ll just do it with less information.
Doesn't this ignore the glaring difference between a plumbing task and a software task? That is, level of uncertainty and specification. I'm sure there are some, but I can't think of any ambiguous plumbing requirements on the level of what is typical from the median software shop.
Sorry, I edited the plumbing refence out of my comment because I saw a sibling post that made a similar point.
I agree there is less uncertainty in plumbing - but not none. My brother runs a plumbing company and they do lose money on jobs sometimes, even with considerable margin. Also when I've needed to get n quotes, the variation was usually considerable.
I think one big situational difference is that my brother is to some extent "on the hook" for quotes (variations / exclusions / assumptions aside) and the consequences are fairly direct.
Whereas as an employee giving an estimate to another department, hey you do your best but there are realistically zero consequences for being wrong. Like maybe there is some reputational cost? But either me or that manager is likely to be gone in a few years, and anyway, it's all the company's money...
I bet if SWEs were seeing anywhere near that 1.5k per day they’d be more inclined to pay attention.
But when you get paid less than half that it doesn’t feel like a problem to worry about. At 300/day of take-home pay, one more day here or there really isn’t going to make a difference.
Not a pro data guy but someone running something like what you're talking about for many years. These days 200TiB is "normal storage server" territory, not anything exotic. You can just do the most boring thing and it will be fine. I'm just running 1, tho. The hard parts are having it be efficient, quiet and cheap which always feels like an impossible triangle.
Yeah, resilvers will take 24h if your pool is getting full but with RAIDZ2 it's not that scary.
I'm running TrueNAS scale. I used to just use Ubuntu (more flexible!) but over many years I had a some bad upgrades where kernel & zfs stopped being friends. My rack is pretty nearby so for me, a big 4U case with 120mm front fans was high priority, it has a good noise profile if you replace with Noctuas, you get a constant "whoosh" rather than a whine etc.
Running 8+2 with 24tb drives. I used to run with 20 slots full of old ex-cloud SAS drives but it's more heat / noise / power intensive. Also, you lose flexibility if you don't have free slots. So eventually ponied up for 24tb disks. It hurt my wallet but greatly reduced noise and power.
It's a super old box but it does fine and will max 10Gbe for sequential and do 10k write iops / 1k random read iops without problems. Not great, not terrible. You don't really need the SLOG unless you plan to run VMs or databases off it.
I personally try to run with no more than 10 slots out of 20 used. This gives a bit of flexibility for expanding, auxiliary pools, etc etc. Often you find you need twice as much storage as you're planning on directly using. For upgrades, snapshots, transfers, ad-hoc stuff etc.
Re: dedup, I would personally look to dedup at the application layer rather than in the filesystem if I possibly could? If you are running custom archiving software then it's something you'd want to handle in the scope of that. Depends on the data obviously, but it's going to be more predictable, and you understand your data the best. I don't have zfs de-dup turned on but for a 200TiB pool with 128k blocks, the zfs DDT will want like 500GiB ram. Which is NOT cheap in 2026.
I also run a 7-node ceph cluster "for funsies". I love the flexibility of it... but I don't think ceph truly makes sense until you have multiple racks or you have hard 24/7 requirements.
Very cool. Okay, I think you're right. Doing dedupe at the application layer is a much better idea. I do have 512 GiB of DDR5 (it's an Epyc 9755-based server) but I think you're right because I am fully aware of the data I'm storing (internet archive data) so I can simply delta-code on a per webpage sense.
Right, I knew from /r/homelab that many normal people now store petabytes in their nodes. My specific machine is going to be in a DC located some 1 hr from me so I don't mind noise, but I am particular about power consumption and so on.
Based on what you said I'm going to run RAIDZ2 on this. I happen to have a bunch of EXOS 18 TiB drives so I shall use those. Thank you for the advice from experience!
I have worked in this space, and my experience was that usually age / identity verification is driven by regulatory or fraud requirements. Usually externally imposed.
Product managers hate this, they want _minimum_ clicks for onboarding and to get value, any benefit or value that could be derived from the data is miniscule compared to the detrimental effect on signups or retention when this stuff is put in place. It's also surprisingly expensive per verification and wastes a lot of development and support bandwidth. Unless you successfully outsource the risk you end up with additional audit and security requirements due to handling radioactive data. The whole thing is usually an unwanted tarpit.
Depends on what product they manage, at least if they're good at their job. A product manager for social media company know it's not just about "least clicks to X", but about a lot of other things along the way.
Surely the product managers at OpenAI are briefed on the potential upsides with having the concrete ID for all users.
Making someone produce an identity document or turn on their camera for a selfie absolutely tanks your funnel. It's dire.
The effect is strong enough that a service which doesn't require that will outcompete a service which does. Which leads to nobody doing it in competitive industries unless a regulator forces it for everybody.
Companies that must verify will resort to every possible dark pattern to try to get you over this massive "hump" in their funnel; making you do all the other signup before demanding the docs, promising you free stuff or credit on successful completion of signup, etc. There is a lot of alpha in being able to figure out ways to defer it, reduce the impact or make the process simpler.
There is usually a fair bit of ceremony and regulation of how verification data is used and audits around what happens to it are always a possibility. Sensible companies keep idv data segregated from product data.
> Making someone produce an identity document or turn on their camera for a selfie absolutely tanks your funnel. It's dire.
Yes, but again, a good product manager wouldn't just eyeball the success percentage of a specific funnel and call it a day.
If your platform makes money by subtle including hints to what products to prefer, and forcing people to upload IDs as a part of the signup process, and you have the benefit of being the current market leader, then it might make sense for the company to actually make that sacrifice.
> No one wants to upload an ID and instead is moving to a competitor!
Comments on the internet is rarely proof of anything, even so here.
If no one wants to upload an ID, we'd see ChatGPT closing in a couple of weeks, or they'll remove the ID verification. Personally, I don't see either of those happening, but lets wait and see if you're right or not. Email in the profile if you want to later brag about being right, I'll be happy to be corrected then :)
The average HN user maybe, but elsewhere, I see people uploading their IDs without a second thought. Especially those in the "chromebooks and google docs in school" generation who've been conditioned against personal data privacy their whole lives
There is no way that the likes of OpenAI can make a credible case for this. What fraud angle would there be? If they were a bank then I can see the point.
Regulatory risk around child safety. DSA article 28 and stuff like that. Age prediction is actually the "soft" version; i.e, try not to bother most users with verification, but do enough to reasonably claim you meet requirements. They also get to control the parameters around how sensitive it is in response to the political / regulatory environment.
Random forums aren't worth suing. Legally, reddit is not treated as responsible for content that users post under section 230, i.e, this battle has already been fought.
On the other hand, if I post bad advice on my own website and someone follows it and is harmed, I can be found liable.
OpenAI _might plausibly_ be responsible for certain outputs.
Ah, I see you added an edit of "I think there's also a legal perception that since AI is a new area, anything related to liability, IP, etc might be "up for grabs"."
I thought perhaps that's what you meant. A bit mercenary of a take, and maybe not applicable to this case. On the other hand, given the legal topic is up for grabs, as you note, I'm sure there will be instances of this tactical approach when it comes to lawsuits happening in the future.
It does feel like ensh*ttification. I can't imagine how many school essays and law filings and papers these ads are going to end up embedded in.
But the most charitable view is that even AGI needs cost recovery. Ads are the way you do this for people who aren't willing or able to pay with money.
For better or worse, OpenAI exists in the context of a capitalist system. It has to be competitive in that arena to attract and retain investment, staff, etc. Revenue always ends up being part of the "mission".
The biggest problem with ads is that even if I were willing to pay any amount of money I would still get many of the problems brought by this 'ad run' world. There's enough things where you can't even avoid ads.
It depends on the application but there are lots of situations where a proper test suite is 10x or more the development work of the feature. I've seen this most commonly with "heavy" integrations.
A concrete example would be adding say saml+scim to a product; you can add a library and do a happy path test and call it a day. Maybe add a test against a captive idp in a container.
But testing all the supported flows against each supported vendor becomes a major project in and of itself if you want to do it properly. The number of possible edge cases is extreme and automating deployment, updates and configuration of the peer products under test is a huge drag, especially if they are hostile to automation.
Once, for a very very critical part of our product, apart from the usual tests, I ended up writing another implementation of the thing, completely separately from the original dev, before looking at his code. We then ran them side by side and ensured that all of their outputs matched perfectly.
The "test implementation" ended up being more performant, and eventually the two implementations switched roles.
Fellow old guy here, I think this is _really_ noticeable in shows for young kids, across most mediums. There's been a sort of, not sure what to call it, cocomelonization of everything? You can see it clearly in long running shows, such as Sesame Street.
There are some modern standouts like Bluey but they're rare.
reply