even 100 kB dynamically generated pages should be a piece of cake. if it's CRUD like (original op's site is), it should be downright trivial to transfer that much on like... shared hosting (although even a VPS would be much better).
(in original op's case, i clocked 197 requests using 20.60 MB while browsing their site for a little bit. most of it is static assets and i had caching disabled so each new pageload loaded stuff like the apple touch icons.)
honestly you could probably put it behind nginx for the statics and just use bog standard postgres or even prolly sqlite. nice bonus in that you don't have to worry about cold start times either!
why wouldn't you? these are easily compressible text files. storing even like 100x into a 400 day (at most, the default for GH is 90) box is downright cheap to do on even massive scales.
it's 2025, for log files and a spicy cron daemon (you pay for the artifact storage), it's practically free to do so. this isn't like the days of Western Union where paying $0.35 to send some data across the world is a good deal
we don't need it. we need to run our CI jobs on resources we manage ourselves, and GitHub have started charging per-minute for it. apples and cannonballs
i think that people vastly overstate the costs of this sort of thing and it's super bizarre. if you're treating this as a big official corporation™ and such and want to pay 500 devs like $200k/year or something to make work, then yeah you're gonna have problems.
but if you want to build a social network and aren't dreaming of being gazillionaires for it (which is quite reasonable), then you can get by very easily. how do I know this? because... well it's being done successfully. not was done successfully, is done successfully.
you can probably even get people to help out on it.
you can build a social network with a dedi running nginx hosting your Python application running on a Linux box backed against Postgres (and redis for session storage, although even that is a bit overkill) for like $80/month deployed with a "deploy.sh" script that you run to kick the damn thing into running (Docker is used in dev only, but could easily work here). should you probably add health checks or whatever? yeah. it still works really well.
this scales well past the 100k users mark.
what about video/images/etc? well, this nginx server happily sends out user uploaded video storing them as files on a bog standard ext4 filesystem. backups exist of the site.
the "stack" i mentioned here isn't fancy or particularly tightly optimized, it's in fact pessimized in a lot of ways. hell I know there were a gazillion ways we could improve performance of our application. show the backend app to a game dev and they'd probably want to start strangling people with how poorly optimized most of the actual app is.
and still, it scales well.
again, I stress that this isn't some theoretical idea, this is actively being executed. the entire venture makes money for the team from the users who willingly (and unforcibly in order to use the service, the actual site is free to use in its full form) give money. this isn't ZFS. this isn't Rust. this isn't using some blue-green deployment. this isn't spending hours toiling away at which sysctl to set to squeeze every last cycle out of each box. this isn't behind some massive CDN with "internet scale" boxen or even (for the video serving part) behind any anti-DDoS service.
it's just a matter of doing actual engineering and being willing to actually build the things you want to build.
I like stories like these, but I think you just never hit a breaking point with the infra and approaches you got. You've never exceeded your ext4 volume size, so no need for object storage. You've never had a server die, so one dedi box is fine. You've never had a paying customer call you with an issue, so oncall support is not needed.
yeah, i mean i guess what i'm trying to say is that the breaking point is very far up there as computers have gotten towards breakneck speeds, especially on the technology side, for the goal being achieved. it's downright difficult to hit the limits unless you're throwing effectively a DDoS at it.
i think the big thing though is that it's a community and so people are actually willing to support that even if it means the amount of 9s of availability is slightly fewer (although in practice, many providers bust right through their "9s" SLAs without a care in the world) and given a migration from a VM provider to the dedi occurred, migrations obviously can happen if failure presents itself.
> The US definition of "derivative work" is quite broad, and seems to cover linking just fine.
the problem is the GPL view seems doubtful and has not only bad implications for software copyright but copyright of... well literally anything else. I mean, remember what linking actually is (especially dynamic linking), you're basically just making references to certain things.
the analogy that I can best describe is this: if you're writing a paper on something whatever, and you link to a page number of a book, that doesn't make your paper a derivative work of that thing per se.
if I say in the middle of my novel new text on foobars and fozzinators, hey "book A page 32" has instructions for how to confabulate your fozzinator or "book B page 42" has the values needed to valienate your foobaz, referring to those things in general makes no sense to consider this originally authored book a derivative of A, B, or A and B.
or for a more concrete example, saying Microsoft should be the final authority on who can interoperate with their products or saying that the people who publish research are automatically derivative works of other peoples research[1] papers or people who write articles can't even REFER to other articles in such a way.
[1]: research itself may come from derivative ideas of course, but I'm talking about the copyrightable elements here; i.e. not the facts necessarily presented within, but rather how such facts are presented and laid out. copyright does not cover facts (true or false[2]), but your presentation of such facts are.
I would dispute that pretty heavily. They're not, and obviously have never, claimed copyright over the DLL you made or whatever, nor the entire concept of linking to Windows APIs (as an example).
Mostly because that's, like the GPL, currently a way to get laughed out of court.
it's also worth bringing up some arguments made by Theodore Tso over this very issue in 1998[1]:
> Consider the following --- what defines "link"? Does an RPC call mean linking? What about shared libraries? What about making calls via the system call interface? What about running GPL'ed programs via the system() command from a commercial program? If you take things to extremes, a commercial program which uses the system() program will be interfacing with the GPL'ed /bin/bash on most systems --- is that considered "linking"?
> And if not, what is the legal distinction between what /etc/ld.so does when it maps a GPL'ed library into memory and the thread of control is temporarily tranfered from propietary code to GPL'ed library code when a library function is called, and what happens when a propietary program calls system() and the kernel maps /bin/bash into system memory, and the thread of control transfers temporarily from the propietary program to /bin/bash? You can see how things can get quite ridiculous quite quickly.
> [...]
> The FSF assertion also a very dangerous legal argument to make. If this is true, does this mean that if you write code which happens to make use of interfaces developed by Microsoft and implemented by Microsoft DLL's, that Microsoft somehow has a claim over your code which it could enforce via copyright law? What about any i386 assembly code which makes use of the Intel machine language? Does Intel now have a copyright claim on all i386 object code, and can try to prevent people from executing i386 object code on non-Intel processors? (After all, when a Pentium interprets your object code, one could argue that it is "linking" your object code with the Pentium microcode, which is copyrighted by Intel....)
> What the FSF is trying to advocate is one step down the slippery slope of interface copyrights, and we really, really don't want to go there.
i've seen arguments especially after the Google v. Oracle[2] decision and I think one in particular mentioned the sort of "reality distortion field"[3], which I found to be interesting, especially because a lot of open source projects that are GPL tend to rely on the good-naturedness of other users using their code in a way that's positively in spirit with the GPL. (which, to be fair, has probably helped open source immensely.)
but as Tso points out, therein lies a contradiction with GPL that at if its maximal interpretation to be correct, it's much much more dangerous, than if the GPL effectively is equivalent to the LGPL. but I don't think that (barring a world pre-this-case) this world is the one that is so. (no idea how the AGPL fits into this though, that sounds like a PITA.)
if I were ruler of the world, I'd say that symbol names are a matter of fact and thus should probably not be copyrightable by themselves. but then again I don't rule the world, and I'd probably have other things to change as well, even about copyright.
In this case, it turns out that a technician mistakenly inserted into a NORAD computer a training tape that simulated a large Soviet attack on the United States. Because of the design of the warning system, that information was sent out widely through the U.S. nuclear command network.
was it even reported? i heard a bunch of stuff that seemed to be hypothetical guessing like "satya must be furious" that seemed to morph into "it was reported satya is furious"
i've seen similar with the cloud credits thing, people just pontificating whether it's even a viable strategy.
it's hilarious how much people for no reason, want to defend the honor of Sam Altman and co. i mean ffs, the guy is not your friend and will definitely backstab you if he gets the opportunity.
i'm surprised anyone can take this "oh woe is me i totally was excited about the future of humanity" crap seriously. these are SV investors here, morally equivalent to the people on Wall Street that a lot here would probably hold in contempt, but because they wore cargo shorts or something, everyone thinks that Sam is their friend and that just if the poor naysayers would understand that Sam is totally cool and uses lowercase in his messages just like mee!!!!
they don't give a shit that your product was "made with <3" or whatever
they don't give a shit about you.
they don't give a shit about your startup's customers.
they only give a shit about how many dollars they make from your product.
boo hooing over Sam getting fired is really pathetic, and I'd expect better from the Hacker News crowd (and more generally the rationalist crowd, which a lot of AI people tend to overlap with).
Yeah it’s crazy how much the tech community is defending this random CEO, considering the relatively unsympathetic response to the tech layoffs over the last year.
it's that he has no ethics to speak of at all. it's not that he's out of touch, it's that he simply does not care.
reply