You'll throw Hollywood and most of the publishing industry out of business overnight if you "abolish" copyright. Not a good idea to throw so many people out of work.
Copyright needs to be reformed, absolutely. Not abolished.
Compared to the economic and human disruptions of shipping most of America's manufacturing jobs overseas since WWII, that sounds very minor.
Yes, I understand that Hollywood & publishing carry much higher social status than mere manufacturing, for the "right" people to object at them being tossed.
No, I'm not disagreeing with your "reform not abolish" ideal.
Which side you're taking here? Sudden and Legal are pretty unobjectionable to folks who aren't pro-copyright for other reasons. But could sound excellent to (say) folks who "bought and owned" digital property...then had their access cut off suddenly and legally.
Hollywood was created by ignoring (Edison) patents, not copyright.
On the other hand, Disney's success is largely owed to public domain adaptations, and for a century, it did its best to shrink the public domain and expand copyright.
Your argument is non-sequitur and nihilist. America was created by colonizing Native land, so should we somehow evict hundreds of millions of people in the name of justice? (/rhetorical)
Original sin is a sunk cost. If you want to make the world better, you focus on what's right for tomorrow, not what was right for a century ago.
I don't see an argument for removing copyright being a good thing other than people wanting other's work for free, not just free to use but free to sell as their own.
Was it is a good thing and it was created by ignoring copyrights and therefore we shouldn't protect copyrights as an absolute because other good things can be created out of it, or is it a bad thing and is using that copyright to restrict others.
You can't have it both ways. My point was just that defense of Hollywood is a terrible example.
It's not only Hollywood, these ML tankies that want to abolish private ownership will destroy pharmaceutical innovation. (This is where people's brains will turn off)
Why would a firm invest in research improving Super-Rare-Disease therapies if I don't get exclusive rights to the monetary benefit?
And to the inevitable room temperature IQ DSA crowd, why would the ML government with state research firms ever direct public resources to improving Super-Rare-Disease? Something that affects 1-in-10000 people doesn't deserve public resources like common diseases.
> these anarcho-capitalists that want to abolish private ownership will destroy pharmaceutical innovation
> why would the AnCap government
Do you know what an anarcho-capitalist is? There is no way an ancap would want to destroy private ownership. They also are also anti-government everything.
And how do you know if you have been breached if you (negligently, in my opinion) have no audit logging, multiple principals sharing the same account, and no anomaly tracking? Does a breach only happen if the attacker brags openly about it?
The difference with accounting is that, relatively speaking and certainly within this context, few businesses are cash businesses. Your bank is keeping at least a basic audit log of money coming in and out of the corporate bank account. Your payment processor is keeping at least a basic audit log of who paid you and how much. You won't make your auditors happy if they're the only documents you have, but they're at least something to be handed over in an audit that pretty much every software business will have. Cybersecurity? By default, nothing is collected.
forensic accounting and audits also require a paper trail.
So if you have no logging and such, you will have already failed regulatory reporting standards - just like you would fail an accounting audit if you have no paper trail of where your money went!
Author has a good head on their shoulders, but few if any companies are going to spend time on incident simulations for their SREs.
Why not? Because even pre-AI, very few companies spend time practicing restoring their backups, or disaster recovery, or picking infrequently-used runbooks to practice, or seeing whether they can easily rotate secrets without downtime, or trying to redploy the system onto another vendor's cloud/platform, or, or, or... It is the least-sexy operations work that exists. No executive cares about this. Ops organizations push for flashy work, same as everybody else: new infrastructure for new projects, cool chatbots, new flashy dashboards, make charts go up and to the right, etc.
Airline pilots go through disaster simulation training because the government mandates that training. If it wasn't a condition of holding a pilot's license, no company would pay for it.
Want SREs to spend time training for disasters? Take a step back. Support professional licensure. Make it a condition of holding a license. You won't get industry-wide professional behavior until you professionalize the work. It won't happen without licensing because every corner cut that is not immediately visible to consumers translates to additional profit, and increasing competition eventually requires these corners to be cut in order to keep up with competition and stay in business. Forcing all players to submit to licensing requires all players to pay these costs and thus forbids them from cutting them to become more competitive.
I was the head of a global SRE team at a top tier hedge fund.
We started doing a weekly meeting where whoever was on call would do a table top exercise of an outage that happened the prior week.
The idea was to have someone else be the simulated person on call while the SRE from last week's oncall would talk them through the symptoms, what happened and where to look.
The idea was to spread knowledge around how incidents looked, what tools were used, what could have been done differently etc.
This was largely inspired by the following quote:
"Drills are for working on the infrequent actions that lead to big outcomes. A good example is heaving the ball from half court in basketball when the game is close. You can't control who will have the ball in that situation but you want everyone on the team familiar with what to do and how to do it."
How often are there outages? Is there a significant outage every week to do simulations for? The problem with our organization is that outages are so rare that weekly we have nothing to discuss.
They were usually small outages that we caught before they got out of hand.
If you never have outages, then you need to start getting either creative with the "table top" exercises or you set up a test environment that is very prod like and have someone randomly turn off components aka chaos engineering.
Hmm that’s strange, in my experience it is the other way around - Claude is super diligent with infra and will _insist_ on double checking and trying everything for real before committing.
When I was doing this myself I would read the docs and just implement them - claud is going about doing real software archeology to figure if what is said is actually the truth or it’s stale/inaccurate/buggy.
I’ve become 10 times more diligent because it is a lot easier to do. It’s no longer Urgh it’s good enough let’s ship it, now it’s “sure put a leg on it to figure it out and double check it”.
Backups are _tested regularly_ now because LLMs make it cheap to do so.
The only problem is when new engineers who haven’t learned these things Pre-ai now don’t really get why it is needed in the first place and will often lead the agent astray.
I think to address this we need to change or improve our training routines in general for humans. I think a lot of companies nowadays just skip that and deploy a company wide skill/policy for the agents, but don’t transfer the underlying skills to the devs themselves.
> Backups are _tested regularly_ now because LLMs make it cheap to do so.
sighs heavily in 90's sysadmin
Testing backups is not just a question of whether or not the restore command works. Go back and read the Tao of Backup: http://www.taobackup.com/history.html . The application itself (in its current version, with its current features) needs to work with the backed-up data, and the only way to verify this is to attempt to actually work with the data.
If you don't trust your agent to ship to production without manually reviewing the output (in some way), you have no business trusting your agent managing your backups. The agent writing some tests doesn't mean that the tests adequately handle all of your actual scenarios, let alone that your system will adequately handle data that is missing since the last backup.
>Why not? Because even pre-AI, very few companies spend time practicing restoring their backups, or disaster recovery, or picking infrequently-used runbooks to practice, or seeing whether they can easily rotate secrets without downtime, or trying to redploy the system onto another vendor's cloud/platform, or, or, or...
Exact. Let insurance cover it, say sorry to your customers twice and shwoop never happened.
The stock market isn't fundamentally a gamble. Spending money to buy a share of a company's future dividends is a sound way to invest money and earn a return on it.
The problem with the stock market is when there aren't enough new companies going public to soak up the spigot of all the capital that people want to invest, leading average P/E ratios to increase over time. There is too much money chasing too few earnings. When the underlying fundamentals don't match up, then all that investors are doing is speculating that someone else will be the bigger fool and buy from them at an even more unreasonable price - and that is a gamble.
> There’s lots of things you can blame for killing the open Internet, but I think NAT was one of the earliest. Running a server used to be trivial: run an executable, tell people your address, done... It also trained everyone to think client‐server is natural. “My device talks to The Cloud which talks to other devices” feels normal, when that feeling originated as an artifact of address scarcity.
A lot of this feels like a requiem for the days when the only people on the Internet were "high-computer-skill" type folks. Most people will gravitate to "user-friendly" solutions: Gmail and other managed email providers were popular because they didn't stop working when you shut down your computer to save electricity, when your server's hard drive crashed, when you upgraded your computer to something with a faster processor, more RAM, and a newer operating system. It was hard enough to educate laypeople about URLs and email addresses (AOL keywords, anyone?), let alone a combination of random numbers in an IP address, or convincing people to register domain names.
Yes, NAT shoved fences into a network that was all about connecting everybody. But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. ISPs would have just sold highly restrictive firewalls as part of their home-install basic boxes, and we'd still have ended up with those fences.
There was a point in time in the mid-2000s when P2P networking had briefly made running your own server attractive to end-users again. And then the iPhone came out and completely killed any hope of that becoming the norm.
The thing about smartphones is that they are both completely dependent on wireless connections to central servers in order to function and completely unsuitable to operate as servers. If you forced your phone to serve files anyway, your battery would drain quickly and the CPU would be drowning in its own waste heat. You might argue that you could still do non-server things on the phone, but practically speaking, a node that can't handle server tasks is just a leech. P2P networks work on a mutual aid basis; they require the majority of nodes be capable of shouldering traffic or sharing files in order to be a net benefit. If you add, say, tens of millions of new mobile phones to the network, the network will become unusable as any desktop machine gets DDoSed by hordes of phones asking for a babysitter.
So even in the world where IPv6 did to v4 what v4 did to NCP, we'd still ultimately end up with "my files go in the cloud", because clouds are coinventions of smartphones, in the same way that cars are coinventions of suburbs. You can't have one without the other, and once you do have both, they become so economically dominant that others get socially coerced into using them.
Nokia were experimenting with using their smartphones as web servers in the mid-2000s. You were able to write blog posts and share photos, and if you logged in to the site you could look up your contacts or download your camera roll. There's an article on this here: https://allaboutsymbian.com/features/item/Previewing_Nokias_... .
Obviously it's all very basic, but with a few years of development and polish (and probably someone besides Nokia copying the idea) I think this would be a compelling product. You could basically have the same feature set as something like iCloud but without the subscription or your files going elsewhere.
> But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning.
Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.
But this doesn't only hurt server-y stuff: you may not notice it if you're with a legacy MegaISP with lots of money to throw at IPv4 allocations, but if you're with a younger or smaller ISP, then there's a good chance you're behind CG-NAT, so many console games won't work.
Yeah I feel like a lot of the people criticizing this are still being client-server brained. There's a lot of use cases that "everyone is a server" would open up without turning everyone into a sysadmin and they'd likely get turned into user-friendly software like BitTorrent or Skype or early Spotify.
It's sadly the only practical way to do things now. For client/server, you only need one party (the server) to not be behind CGNAT. For p2p, you need both parties to not be behind CGNAT. It's typically only possible to guarantee that one party isn't behind CGNAT.
All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.
The problem is that everyone who's championing IPv6 is talking about how it makes NAT unnecessary and about how bad NAT is. See TFA as one example. NAT is perfectly fine, so all the IPv6 boosters who make this huge deal of it get dismissed as IPv6 hype men. "Every household gets an IPv4 address which is shared between their computers using NAT" is a good solution.
The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem. It took a long time before I understood this due to all the noise IPv6 people make, but newer ISPs don't have enough IPv4 addresses to give every household its own address, so they use CGNAT for residential Internet access. This is what people should be focusing on, but it's not. All arguments for IPv6 are irrelevant drivel about how bad NAT is.
Certainly there are still (SPI) firewalls with IPv6, but at least with CPEs things are limited to 'only' hole punching with PCP (or UPnP) as opposed to all the ICE/TURN/STUN layers (and heaven help you if you're behind CG-NAT).
> The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem.
NAT was intended to be a "short-term solution" as noted in the NAT RFC (from 1994):
> A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.
This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port.
More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port.
(I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)
That's fine. Based on my recollection I don't agree with your thesis (or think it's at least greatly exaggerated) but reading source documents from the past and advancing an argument is solid history scholarship.
> Running a server used to be trivial: run an executable, tell people your address, done...
This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.
And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.
1. NAT and a firewall are 2 different things
2. With IPV6 you can have so many IPS that unwanted users can't guess your IP. This isn't true security but see 1 for that.
Exactly. Which is the issue with saying, as the article does, that NAT is the reason most people don't have an Internet visible server, when the real reason is that their computers need to be behind a firewall and once you're behind a firewall, safely opening up just little pieces of it for an Internet visible server is something most people aren't going to want to deal with.
Perhaps a server run by a large corporation could do this. Perhaps.
But an ordinary person? I don't see it. If it's tough for an ordinary person to handle safely opening a port in their firewall for forwarding, it's tough squared (or perhaps cubed or an even higher power) for an ordinary person to handle auto-creating a separate IPV6 address for every other person that wants to communicate over the Internet with them.
Not to mention, how does this work with DNS? If Ordinary Person wants to put an article up for others to read, how do the others find it? Surely not by Ordinary Person sending individually crafted IPV6 addresses to anyone who wants to read their article. (And how do they even find those other people if they are also creating new IPV6 addresses for everyone else?)
> most of the time they are unwanted users trying to break in
Thankfully, we have wireguard now. It drops all packets by default. From the perspective of people who don't have the requisite cryptographic keys, it's like the computer is not even there to begin with.
I've always found it strange how people just put computers out there on the internet and just allow them to interact with total internet randoms. Why are we allowing our computers to talk to strangers? No wonder people are getting hacked.
If the utility and functionality of the server requires those things, then they're required regardless of whether or not that server is internet-facing.
Jill from Elbonia may be always be a threat, but this doesn't mean that Joe from Accounting is not a threat or cannot ever provide a vector for Jill. :)
I mean, no, you don't have to worry about all that stuff unless the business logic demands it. The OP is entirely correct for eg just serving a static file.
It's classic HN to criticize OP that their solution doesn't scale, and then for OP to respond by saying that they don't need the scale and anyway PG tells you to do things that don't scale.
SQLite is great for small-production scale. Don't let anyone tell you different. Just keep in mind that it's a pain to move if you ever do need to scale up. If it's a startup, you might. If it's a weekend hobby project you're building for your personal use only, you probably won't.
By definition, paying employees well means paying them above-market, not market rate. If you pay people market-rate, nobody writes home about the compensation. Market-rate is also not "underpaying" i.e. below-market.
Paying above-market rates is walking a tightrope. On the one hand, experienced employees who are well-versed in your systems and your organization are indeed worth more than market-rate (i.e. someone new), and compensating them as such will retain them. On the other hand, it also retains poor performers, who you want to steer to finding roles elsewhere. Being ruthless about firing fast is one option, but it's a deal with the devil - it erodes psychological safety among people who stay unless the firing is unanimously desired and there is a consensus among everyone who remains that it was necessary. So if you handle the firing wrong, you affect performance and social cohesion everywhere. If you pay market-rate, it's easier to just make someone miserable until they self-select out and find work elsewhere.
Unfortunately (or fortunately?), all successful startups pay above-market because equity compensation in the right company can be a life-changing amount of money. So most successful startups seem to successfully walk that tightrope.
I define market rate to be the best rate that somebody will pay for your talent (minus Faustian outliers).
"Above-market rate" is an oxymoron. If someone is offering to pay you above the prevailing best rate then obviously you're going to sell to that buyer and it becomes the new market rate.
It really depends on the organization, its mission, the employee pool, and the local cost of living.
Most software engineers are relatively well-paid compared to the wider labor market, even the engineers who are "underpaid". Kahneman's research showed that once you have enough money to pay your bills, making more than that has rapidly diminishing returns for your happiness. It's much more important to fit in - like your boss, like your coworkers, like your work, be recognized, have good work-life balance. None of that really requires above-market compensation.
When a firm pays below-market rates, it's a sign of one of two things: either they're abusing people who can't find work elsewhere, or people are happy to stay in spite of it. The latter are often really good places to work.
HN loves to complain about how money ruined the software industry. Let the people who will chase a raise from $180k to $210k go elsewhere. Let the people who want their moonshot at life-changing wealth go talk to a VC. There are other opportunities for people who realize that money isn't everything in life.
I don't think we actually disagree here. I agree broadly with everything you said. My point was mainly I don't see a reason to support that assumption that if pay pushes out low performers, I don't see a reason why it wouldn't equally push out high performers? This goes on the assumption that lower performers optimise more for pay than higher performers?
Low pay pushes people to leave, regardless of performance. The argument I'm making is that, in such an environment, you retain high performers through non-economic incentives (sense of belonging, appreciation, etc.) and push low performers out by not providing those. Why would anyone ever stay in an environment that also underpaid you and where you also weren't appreciated and gave you subtle hints to leave? Under-paying actually makes it easier to push out the people you don't want. Under-paying does indeed risk pushing out high-performers; my argument is that this is risk and not a guaranteed destiny, and that high-performers may be incentivized to stay by other means.
Even startups that beat the incredibly long odds to become successful mostly aren’t successful enough to make up for a long stretch of not earning BigCo RSUs.
> Next time, I’m picking a tool based on developer experience first, not AWS service integration convenience. The time we lost debugging Cognito issues could have paid for several years of a paid auth provider.
How many paid auth providers let you export user password hashes so that you can seamlessly migrate to another vendor, if you want to?
The whole problem with auth is that both (a) login screens are shown to unauthenticated users, which is a superset that includes attackers, who will do everything from DDoS to crafted malicious input to try to grab user secrets, so you really want to pick something that is already running at large production scale and with all the production battle-scars, and (b) that need to go with a managed vendor is very much in tension against local development, vendor independence, data portability, and other Good Engineering Practices (TM).
Sure, AWS Cognito sucks. In many ways, the product feels stuck. Making compromises to get stuff shipped, working, and stable sucks. But honestly, unless you're going to prefer (b) over (a) (and there are times to do so, in particular with intranet applications behind a firewall that aren't really susceptble to those kinds of attacks) and pick something like Keycloak, you could do a lot worse than Cognito (shudder, Okta, shudder).
Counter point: How many paid auth providers force you to create an entirely new deployment and then use a lambda to migrate within their own system? Especially for something as seemingly simple like adding another metadata field?
I think they allow export because they drew some interesting lines around their own mutability concerns.
Auth0 and Firebase both let you export user password hashes (though I believe you need to open a support ticket in order to do it in Auth0's case at least).
I think Cognito is actually one of the few with absolutely no path to achieving this.
Entra External ID does not allow export of password hashes.
It actually doesn’t allow a whole shitload of stuff that should be there by now.
For example, it supports passkeys, but has no UI for adding or managing passkeys. You have to build that yourself. In a separate app, on a separate domain.
Personally I feel the password migration feature should never be supported. Its ripe for abuse once you open up a pathway to it. SCIM as a protocol was meant to solve this problem, if everyone could just implement it.
Yup for the Ory managed service (Ory Network) you can export all data through the admin API including hashed passwords.
Of course when self-hosting Ory you have full control over the database as well.
DynamoDB has basically two legitimate use-cases that I'm familiar with:
1. You're selling a system to a customer to use within their own AWS account, that you will have no access to, and it needs a transactional datastore (not just an object bucket) of some kind. The fact that it costs nothing by default (particularly valuable when the customer is trying to deploy a proof-of-concept), scales more-or-less perfectly without anybody touching it, requires zero day-to-day maintenance by you or the customer, and all it will ever ask is that you throw money at it, is very, very much a feature. One example I'm familiar with in the wild is Teleport: https://goteleport.com/docs/reference/deployment/backends/#d...
2. You have a huge OLTP workload that fits Dynamo's KV patterns (e.g. Amazon.com shopping carts, which is what it was originally built for). You don't care how much DynamoDB costs (in either dollars or engineering limitations) because any alternative would melt your face off if you even tried.
Most of the pain that comes from Dynamo is people who try to use it as a primary datastore in place of a relational database just to get the serverless pricing model. It's not worth giving up the flexibility on greenfield systems. It does become worth it to give up the flexibility when your system is mature and you don't have genuine flexibility anymore anyway.
Anyone trying to use a kv store for relational workloads is The same kind of person who uses a kv cache with durability features instead of a kv store. You can’t blame the tech for their mistakes.
> Broader, cheaper access to frontier intelligence at incredible speeds is coming.
OP's entire argument rests on this presumption, and while it certainly sounds like the industry is headed in this direction, it's definitely way too early to equate the success of building proofs of concept with success at maintaining mission-critical production systems across industry verticals, as OP attempts to:
> The prototype is working software. And the improvement and testing of that prototype is further enabled by more improvement loops with the AI. It gets better with more testing and verification, not through human code review, but through usage and testing.
Who drives usage and testing today? Who takes user feedback from the "usage and testing" and translate it into something that The Machine can use for improvements? Humans do. There is no agentic harness for managing at the level of the product itself, and I'm not convinced that there ever will be, because it's a fundamentally political concern. And not the low-stakes intra-team kind like tabs vs. spaces - the high-stakes, do-we-close-the-deal-or-not kind. Even if agents hypothetically could handle that level of stakes - they simply lack the context to do so, and will continue to lack the context to do so, at least until we get AGI in a humanoid robotic form factor.
Software engineering isn't dead. As a separate field with a dedicated job title, it's arguably dying in a world where it becomes a table-stakes skillset for Product roles. It is simply cheaper to employ 2x Product Engineers at $300k/year each, armed with $200k/year each in tokens, than it is to staff out a team of eight Software Engineers at $150k/year each. And this is before a hypothetical crash in API token pricing, or agility benefits from aligning fewer humans.
It's happening slowly in smaller companies, and hasn't happened yet at scale because, while you can teach Product skills to most Software Engineers and can't teach Software skills to most Product folk, most big-cap executives haven't gotten this memo yet. But the economic pressures are there.
Copyright needs to be reformed, absolutely. Not abolished.
reply