Sam is very clearly in the wrong here, but is your argument for why he sucks seriously that he said “we should not brand people as heretics for disagreeing with my point of view?”
we should not brand people who make qualified and substantive points as heretics, but his framing is wrong and a common abuse of the notion of the 'marketplace of ideas'.
Inherent to the functioning of debate is that debates are settled, just like exchanges in a market. That's their only function. Constant debate of an ever-increasing number of talking points, by definition, renders any notion of progress impossible. So when Sam draws on Galileo as a figure, the conclusion is not, we need to listen to him because he's a human being but, we needed to listen to him because he made a substantiated point. The reverse is obviously silly, nobody in physics argues that we need to debate geocentrism in the year 2024 to advance modern physics.
Likewise not debating someone who just makes random homophobic remarks doesn't impede the progress of the sciences, it doesn't even impede the progress in ethics. Even the reverse is true, horrible regimes with no free exchange whatsoever still produced a lot of novel physics.
>Inherent to the functioning of debate is that debates are settled, just like exchanges in a market. That's their only function. Constant debate of an ever-increasing number of talking points, by definition, renders any notion of progress impossible.
Some debates might be settled for some time, but I don't think "settled" is inherent in the functioning of a debate, and certainly not any sense of permanence even if they are "settled" at the moment. Were that the case, we wouldn't right here and now be debating what is clearly "settled" free speech policy of "you have to allow shitty people to say shitty things" (see National Socialist Party of America v. Village of Skokie).
Or maybe I have that wrong and the settled policy is "socialist aren't allowed to tell you to resist the draft" (see Schenck v. United States).
I imagine if we went further back in time, plenty of people thought the debate over the legal status of slaves was "settled". Similarly the divine right of kings was "settled" as well.
Or back to more modern times, I imagine the "settled" rightful disposition of say Palestine, Taiwan or the Ukraine to depends an awful lot on where you live.
>plenty of people thought the debate over the legal status of slaves was "settled"
Are you saying plenty of people don't consider it to be settled now? Not knowing you personally I'd be willing to bet almost any amount you are not genuinely open to be persuaded by a pro-slavery or divine monarchy debate. People weren't argued into their shackles and neither were they argued out of them. Just look at the US DoI. It says "we hold those truths to be self-evident.." not "we invite you to make a pro and con list of everything every so often" and hash it out again.
When debate is productive the most important qualifier is never free, it's always reasoned and on shared moral principles. Borders are so violent exactly because they're truly "up for debate". Geopolitics is in a real state of anarchy. The logical endpoint of which is might makes right physical conflict. Mind you European borders today are not "debated" that way, and we consider that a win. If someone said "All European borders must be up for debate!" you'd be somewhat concerned.
I mean, that is precisely why US domestic debate is increasingly breaking down and violent. Not because it's not free enough but because it's too free. Because there's no ethical or rational ground underpinning it. So Sam has it exactly wrong. A community that has no shared conception of the fundamental rights of its people is likely in no condition to debate anything.
>Are you saying plenty of people don't consider it to be settled now?
Clearly some people don't, or the modern slave trade would not exist. Never mind that the US depending on your point of view continues to have slavery in the form of prison labor. And then we can get into what I personally consider hyperbolic descriptions of wage "slavery" that others I'm sure do not consider it so hyperbolic.
> Mind you European borders today are not "debated" that way, and we consider that a win.
Up until very very recently I suspect quite a few Irish and British nationals would have disagreed very strongly on that front. Even today I imagine there are some that don't consider it settled. 1998-1999 brought us the war in Kosovo. Famously there are still protests surrounding Basque independence in Spain, and similarly in 2017 there was the Catalan declaration of independence. Heck a good portion of the readers on this site are probably older than the current unified borders of Germany (34 years). I would also remind you that the Ukraine is a European country whose borders and independence are actively and violently up for debate currently. And none of that counts any of the various European colonies that were divested (in sometimes quite violent ways) in the last century, regardless of the border stability of the home country.
>I mean, that is precisely why US domestic debate is increasingly breaking down and violent. Not because it's not free enough but because it's too free. Because there's no ethical or rational ground underpinning it.
And I see it as almost the exact opposite. I see the breakdown as an increasing unwillingness to ascribe any ethical or rational ground to the opposing side. I think it's compounded by an unwillingness to debate the starting axioms before trying to debate the higher level topics as well, but conveniently if you just assume your opponents have no "ethical or rational ground underpinning" their debate, you also don't have to bother with debating those baseline axioms.
Ukraine is a European country whose borders and independence are actively and violently up for debate currently.
There's no "debate" about the legal borders of Ukraine, or its status as an independent country. There's a war going on of course and an endless stream of propaganda, mostly from one side. But it's not like there's anything resembling a disputed border, or any other unsolved historical issue that's driving the conflict.
BTW it's not "the Ukraine", but "Ukraine" simply (and yes the distinction matters).
> >plenty of people thought the debate over the legal status of slaves was "settled"
> Are you saying plenty of people don't consider it to be settled now?
Many ultra-conservative Muslims do not consider the issue of slavery to be "settled", in they argue that slavery is still permissible under Islamic law, and consider principled abolitionism to be heretical. Examples include Saleh Al-Fawzan, [0] the most senior Islamic scholar in Saudi Arabia, and Daniel Haqiqatjou, [1] a controversial American Muslim with a knack for social media–to say nothing of the leadership of groups such as ISIS and Boko Haram.
Now, this is clearly a minority opinion in contemporary Islam–maybe you could even say "fringe". Still, if it is fringe, it is a fringe that likely numbers in the millions worldwide – and thus counts as "plenty of people".
And, so nobody thinks I'm unfairly picking on Islam, it is not the only major religion in which slavery is still defended. In the 1980s, Rabbi Meir Kahane introduced a bill into the Israeli Knesset, providing for (inter alia) the enslavement of the Palestinians. The Israeli political class found his bill so offensive, they attempted to prevent him from introducing it – but the Israeli Supreme Court ruled that in a democracy, a democratically elected member of the legislature could not be denied the right to introduce a bill, no matter how abhorrent its content. His bill included clauses such as "Non-Jews will be obliged to assume duties, taxes and slavery. If he does not agree to slavery and taxes, he will be forcibly deported". One MK compared it to the Nuremberg Laws; it was near-unanimously rejected. Yet, before one dismisses the late Rabbi Kahane and his followers as some tiny irrelevant minority, consider that one of his devout supporters, Itamar Ben-Gvir, is currently Israel's National Security minister, [2] and there are at least tens of thousands, possibly even hundreds of thousands, of Kahanists in Israel today. And proslavery views in Judaism are not limited to Kahanism; the American Haredi Rabbi Avigdor Miller (died 2001) was an ardent anti-Zionist (on religious grounds), and hence radically opposed to Kahane's ultra-Zionism – but he also "defended slavery as an ennobling institution that should not have been abolished" [3]. And, Miller is still very popular in Haredi Judaism, and while it would be wrong to assume that every Haredi Jew agrees with Miller on this, it appears quite a few (possibly even "plenty") of them do.
Christianity, too, has its contemporary slavery advocates. The American Calvinist theologian R. J. Rushdoony (died 2001) founded the "theonomy" movement, which argues (contrary to most Christians) that Old Testament laws should still be applied in the present day, including the biblical laws for slavery. Rushdoony argued that the Bible "recognizes that some people are by nature slaves" and that antebellum American slavery was "generally benevolent". [4] And again, while you might want to dismiss the theonomy movement as some minuscule irrelevant fringe, its leadership has close links to the current speaker of the US House of Representatives, Mike Johnson. [5]
I get the feeling you may not have gone 0-1 on an API before. In general, you have 1 consumer when you're starting off, and if you're lucky your API gathers more consumers over time.
In that initial implementation period, it's more time-consuming to have to update a spec nobody uses. Maintaining specs separately from your actual code is also a great way to get into situations where your map != your territory.
I'd instead ask: support and use API frameworks that allow you to automatically generate OpenAPI specs, or make a lot of noise to get frameworks that don't support generating specs to support that feature. Don't try to maintain OpenAPI specs without automation :)
How is adding 10-20 lines, depending on how many structures you're creating, and then re-running a generation tool (or simply just running a build command again depending on your build configuration) time consuming? I've written OpenAPI-first services both at Big Tech for services handling crazy amounts of RPS and at tiny seed startups where we release the API and literally nobody uses it but our app. Sure I've run up against the occasional sharp edge/incompatibility with some form of nested structure and the generator we used but it was usually a minor diversion and represented 20-30 min of wasted time for the occasional badly-behaving endpoint.
I'm even writing a side project now where I'm defining the API using OpenAPI and then running a generator for the echo Go framework to generate the actual API endpoints. It takes just a few minutes to create a new API.
I don’t agree with you. Write a spec, use generators to generate your servers and clients, and use those generated objects yourself.
The point is twofold: you test your API immediately AND you get a ton of boilerplate generated.
So many products out there just feel like a bunch of separate things with a spec slapped on top. Sometimes the spec doesn’t make sense. For example, the same property across different endpoints having a different type.
Save yourself time and do it right from the get go.
> Maintaining specs separately from your actual code is also a great way to get into situations where your map != your territory.
So yeah, write your spec once and generate all servers and clients from it…
OpenAPI spec seems intended to be consumed, not written. Its a great way to convey what your API does, but is pretty awful to write from scratch.
I do wish there was a simpler language to write in... JSON-based as well that would allow this approach of writing the spec first. But alas, there is not, and I have looked a loooot. If anyone has suggestions for other spec languages I'd love to learn!
OpenAPI specs can save weeks even on small projects, when you need to autogenerate multiple clients in different languages after the API part is ready btw
That particular line has been in the system prompt for a long time. It's from the Web Browser model prompt and I remember it being there before they merged all the models (DALL-E, Advanced Data Analysis, Web Browser) into a single combined model.
They explicitly said so, phrasing it as "laziness", on their blog post.
"""Today, we are releasing an updated GPT-4 Turbo preview model, gpt-4-0125-preview. This model completes tasks like code generation more thoroughly than the previous preview model and is intended to reduce cases of “laziness” where the model doesn’t complete a task. The new model also includes the fix for the bug impacting non-English UTF-8 generations.""" - https://openai.com/blog/new-embedding-models-and-api-updates
This looks like an interesting take on serverless Postgres! Is this type of multi tenant separation enough for the kinds of users who care about it? I’d imagine a lot of the concerns around multi-tenant would be related to potential application layer bugs that can co-mingle data.
Data isolation, recovery, backups are a big problem in the world of SaaS, especially at huge scale. Companies end up hiring a dedicated infra team to handle such issues.
Makes sense, but if you're doing multi-tenancy, why not deploy a postgres database for each user so co-mingling is not even possible? That would make on-prem deployments easier to migrate to as well.
Nile lets you do this without incurring the operational complexity of managing multiple databases. We let you place the virtual tenant DB either on one multitenant Postgres DB or a dedicated Postgres. So, you can actually create a dedicated one for each of your tenant in Nile but interact with them like a single Postgres instance. We take care of schema updates across them, client-side routing and metadata management
> We let you place the virtual tenant DB either on one multitenant Postgres DB or a dedicated Postgres.
Sounds promising, but by "a dedicated Postgres." do you mean a different server or just a different db on the same server? I'm trying to get at how the cost would change between the two solutions. Right now we can run N databases on the same Postgres server for roughly the same cost as running a single multitenant db. Switching to "server per customer" seems like it would be cost prohibitive.
We are going to support a database in the same server initially but could also provide dedicated server in the future. The nice thing about Nile's design is that we can provide different placements for different cost profiles with the developer experience of a single Postgres instance.
I remember getting an interview question wrong when I said "yeah a get is supposed to just respond with data but you're writing it, you can make it do whatever you want"
I mean most GET requests have at least one side effect: one or more cache writes.
I’ve also implemented some GET endpoints that are a GET but have a side effect of marking something as read. (Normally as a variant to an existing endpoint for sessioned user).
I would expect at a minimum though if you are doing writes during a GET it should be idempotent.
Well, caching a response to a GET request is always going to be subject to variables like Etag and other hashes of the request, time limits, etc. which all ensure that responses, even old responses, are never _wrong_, they're at worst _stale_.
That's different, and safer, than something like a "read" bit on an entity, presumably tracked in an application data layer. I don't think you can mark something as "read" in your application from a GET request. Even if your server sees the response to that GET request as successful, it doesn't necessarily mean that the requesting client actually successfully received the response. As one of infinitely many possible counter-examples, consider a middlebox between a client and your server, where one client request to the server may generate N requests from the middlebox to the server.
While you might technically correct about using a GET to mark a “read” bit as correct on some activity, in reality there’s a trade off to doing it in a PUT.
Let’s say you have some notification resource which is a link redirecting to the thing that triggered the notification. Ideally the notification will automatically be marked read after the user sees the thing they clicked.
My setting the read bit in the GET that makes the redirect you open up. 2 negative possibilities:
- if someone could guess the GUIDs of the notifications they could CSRF a users notifications as marked read. (Unlikely and low impact if it does occur).
- Adds the potential that the client may not have loaded page after the redirect and seen the resource.
There is a UX tradeoff now though if we make this a separate PUT after the page loads:
- in a web application context the user will have to either enable JavaScript so the app can automatically mark this as read or have a separate form on every landing page to mark it as read.
Another alternative would be to make this a POST form to view the notification that redirects but you have in effect the same issue of the user maybe not loading the page after the redirect.
At the end of the day for something as minor as a notification being marked read (as a result of a user clicking directly on it), some idempotent modification can work out and be easy to implement.
Now to be clear I am referring to a purpose built endpoint for a web application.
We expose 1000s of truly restful endpoints that are used outside of a web context and something like this doesn’t really make sense for them.
You probably wouldn't use a PUT for anything like this, true. But if you're going to mark a message as "seen" in a way that would impact a UI widget like an "unread notifications" red dot, then you almost certainly want to make sure that the state-changing request for that message is a POST, not a GET.
There are just so many ways for GET requests to be delivered to a server (or load balancer, or IP, or domain, or...) multiple times for a given client request. That capability is built in to HTTP and exploited in more places than you can ever hope to account for, or even detect.
POST is a kitchen sink. It can do anything. If it creates it must return a 201 with the new resource's location, otherwise if it succeeds but does not create a new resource (just modifies one) then it must return 200.
> 23 year-old data scientists should probably not work in start-ups, frankly; they should be working at companies that have actual capacity to on-board and delegate work to data folks fresh out of college.
If a 23 year old manages to get a data science job at a startup, and then actually delivers the results that the start-up expected of them, the learning experience there is infinitely more valuable than going to Google and using a bunch of tools that don't exist in the real world, on unrealistic timelines because you're not on the ads team and don't need to make money.
You can go learn "best practices" later, but working in a startup is an exercise in pragmatism. You deliver results, or you die.
In general, tech people are more likely to be early adopters. Also, it helps if the VCs you're targeting can log in as well. Same reason most mobile startups are iOS well before they're Android.
In general it goes (GitHub if you're a dev tool, Apple if you're mobile), Google, MSFT, other SSO, in that order.
Wouldn't a generator like this significantly increase risk of succumbing to dictionary attacks? I probably just don't understand part of what it's doing, but I'm curious.
It depends on what your baseline is. With knowledge of the generation algorithm, a dictionary attack on a password generated that way will definitely succeed, but on average it will take 2⁸³ tries (twice that at worst). At a billion tries per second this is 300 million years, almost long enough for the Sun to engulf the Earth if your attacker devotes only a single CPU to the task. There are commonly used password hashing algorithms that can only do a few hundred tries per second per CPU, which pushes the average success time to a quadrillion years, fifty thousand times the current age of the universe.
By contrast, trying every phrase of 20 words or less in every book that has ever been published would only take something like 129 million × 19 × 500,000 = 1.225 quadrillion tries. At a billion tries a second, that's only two weeks. (And if the password hash is inadequately salted, the attacker can use a rainbow table and put in that effort ahead of time and distribute it across all the victims.)
An attacker with more resources might devote a million CPUs to the problem, which would cut the time to success from 300 million years down to only 300 years (assuming a billion tries a second). In the next few decades it will become practical to devote much larger amounts of computation to problems like this, so such an attack might succeed, but currently it is beyond the capabilities of all but a few adversaries. And, as I understand it, Grover's algorithm will enable a large enough quantum computer to solve your password in only 2⁴² tries, which is only about four trillion tries, under an hour at the billion-tries-per-second speed I suggested above. I'm not sure, but I think it would need to prevent qubit decoherence for that period of time.
You can get equivalent security with a shorter password that looks like random gibberish, such as b7fc d750 9a52 ad6a e48c a, eedgckeimbjdefhcjclmghh, mgujdlrgdfmadtlidu, 1qvrx21zego0scvyi, 17uUPBKnfX7fSNY, >4h)&crV,+E{O, or 宜潨阰揫難侌, but those are a lot harder to memorize. They're shorter to type, though, and they're less vulnerable to side-channel attacks.
Looking random isn't good enough, though. They need to actually be random.
