Whether or not it counts as social media, there is no algorithm targeting individuals as far as I know. Social media in the sense of HN is just the internet.
It does, but as you really can't get money out of it in a reliable way by exploiting the user addictive behaviors, it doesn't have that effect on society.
It's just a cool place to visit now an then an check cool stuff out.
Kind of interesting how many people don’t realize that the purpose of Hacker News was to be an advertisement for Y Combinator and their portfolio companies.
You don’t see it as much these days, but YC portfolio companies can post privileged threads on this site for job listings, which in practice double as ads for the company. You’re not allowed to comment on them.
I haven’t seen one for a while because I suspect every company is already inundated with 1000 applications for every job in this market, but this is what Hacker News was for.
Y Combinator is right there in the URL. People know and don't care because it's a well run forum with interesting discussions, the privileged posts don't change that.
I think most people know this and are fine with it. YC owns the site and advertises their stuff on it sometimes. The site itself is not trying to milk you for every penny or trying to exploit you.
I think it is part of Web 2.0 with its user-generated content, but I think it lacks most of the central aspects of Social Media:
- contacts/friends
- personalisation
- followers
I think some central feeds + comments are not enough, especially with the weak user profile concept (I mean, there are not even profile pictures). But I think some people consider HN Social Media.
We have social media-like systems going arguably Compuserve and the like, as well as games. There's a matter of "refinement", like how some older people describe the change of drugs over the decades. TikTok, Twitter and many of the games are just "too strong", and it matters. Nobody gets "addicted" to Mario 3 or IRC to the point it resembles alcoholism.
> Nobody gets "addicted" to Mario 3 or IRC to the point it resembles alcoholism.
People definitely became internet junkies in the past. IRC was where you could find chronically online people before that term was popular.
The good old IRC quote databases were full of jokes about people not leaving their house and being online all the time. I remember being mocked in IRC rooms because I was out doing things instead of being on IRC all weekend. IRC was the place for the chronically online. This has always been a thing and it’s weird to see it dismissed so casually.
If you want to be pedantic, everything that has user interaction I think technically counts as social media. So just about any forum on the internet counts. But there's a pretty big difference in an anonymous forum, and something like twitter, facebook etc.
because we're not putting our personal lives on display here. it's a news aggregator and discussion forum. sure, some folks post their personal projects, but it's framed as news to be discussed, not desperation for validation.
a) real pseudonymity
b) no photos/videos
c) no infinite scroll
d) no notifications
e) very specific (mildly speaking) topic range
f) very very good ranking and filtering algo
....
(g) guidelines designed for curiosity and intellectual discussion that are enforced by the moderators. No "real" social media platform has anything similar. (so maybe it's more like a discussion board? LessWrong/old phpbb forums)
So you're arguing the crusaders brought peace to the middle east?
This history is so vast I can't even begin to think about how to compare. But one thing that feels odd to me is how people think of the middle east as somehow separate/far from Europe when in fact it's basically the same neighborhood. The Greek and the Romans were there. Under the Ottoman Empire, Muslims from present day Bosnia moved to present day Israel: https://en.wikipedia.org/wiki/Bushnak
Don't forget that Christianity came from the middle east and ofcourse Islam.
The Ottoman Empire ruled vast swaths of present day Europe. Spain was under Muslim rule until 1492.
It's all one big mesh. Just yesterday I learnt that many present day Yemeni trace their roots to the Levant. Very different than farther regions like Afria, China, India and ofcourse the Americas, Australia etc.
Can anyone explain why I would want to use this over an orchestration tool that lives outside the DB? Read through the Readme and some of the examples, I still don't get it.
Snapshot PITR of your database means everything restores including the durable jobs at the PIT.
Don't need to synchronize the backups with anything else that is part of the same data store, good for ETL pipelines and other state machine type jobs.
If your ETL is mostly SQL anyway, then having the actual job being run on the same server helps as well.
Yes, but that doesn't have to imply that the compute part of the durable jobs framework also needs to be part of the database snapshot. You almost certainly want that defined in code anyway, if only to have a sane versioning story. So then by having it also be part of the snapshot, you've now got the problem that there are apparently two sources of truth for that bit of the code.
Contributor here. At Microsoft, our Postgres customers seem to split pretty evenly into 2 camps, those that want to do as much as they can in the database, and those that agree with your take - want to keep apps and compute outside the DB.
I bet this is correlated with how much they like/know Postgres already. When people don’t understand their database’s features, they want it to behave like something else they do understand (code). They’re leaving a lot of performance on the table by not leveraging everything their database can do.
Understanding and deciding to rely upon are not the same. Complexity is one of the biggest challenges in real world software systems. Keeping a subsystem’s responsibilities simple can do a lot for a system’s reliability. Most teams have extremely mature systems for managing complexity in their code - tests, CICD etc. Sure you CAN build all those things for your database too, but it’s more work. Most teams I’ve worked on choose to minimize database migrations because it’s a lot of work to make that part of the system as robust against mistakes as code is. Choosing to ignore a feature in your database is often a very rational pragmatic choice aimed at keeping complexity under control.
Yup. Anymore, “we’ll handle that in code” reads to me as “I don’t understand my tools, and don’t want to learn.” Or hubris. The sheer number of times I’ve seen data integrity errors because someone didn’t think they needed a database-level constraint is too damn high.
The other one (also related) is normalization. They’ll have hundreds of millions of rows of duplicated, low-cardinality strings, because “joins are expensive,” while somehow missing the fact that the increased I/O from reduced page-packing also has a performance cost.
Yeah but the increased I/O is cheaper. It's easier to add another webserver as opposed to upgrading your db server.
And I don't think it's as simple as you make it. So where I work we use amongst other things Rails. There are places in our codebase where using joins just isn't feasable cause the database would use too much memory and let's just say N is large.
But since we use Rails we can have it query the tables apart and join the tables through the defined model. We literally save like 20 seconds in some cases because 1 HUGE query becomes 8 straightforward ones with maximum index usage.
And because we have this capability in Rails we would never use something like this, cause that would neccesate us holding two mental models and have a clear "what do we run where" directive which honestly is a PTA.
That sounds like you’re either joining on an unindexed column, or have outdated statistics. 8 queries implies 8 tables, which is well under the limit for both Postgres and MySQL where the planner may give up and choose a suboptimal plan. You may have something like “SELECT * FROM foo JOIN bar ON foo.id = bar.foo_id WHERE bar.baz = 'qux'”, and if there’s no composite index on (bar.foo_id, bar.baz), the planner will choose whichever column it thinks is more selective; it then has to go get the value for the other one, and that can be quite expensive at scale. Even if you have a separate index on each of those, there’s no guarantee the planner will decide to merge them.
> Yeah but the increased I/O is cheaper. It's easier to add another webserver as opposed to upgrading your db server.
I’m referring to I/O on the DB. Rows are stored in pages that are generally 8 KiB (Postgres and MS SQL Server default) or 16 KiB (InnoDB default). If you can fit 200 rows per page, a given query will probably have to fetch fewer pages than if you can only fit 100 rows per page.
> 8 queries implies 8 tables, which is well under the limit for both Postgres and MySQL where the planner may give up and choose a suboptimal plan.
I'm not sure thats true for Postgres. optimal join ordering is np-hard, and finding an optimal join requires exhaustive search through n! combinations (n=number of joins) - thats why postgres generally uses heuristics to figure out join order. 8 is also the default value of "join_collapse_limit" setting in postgres, so it can't ever reliably optimize over 8 joins at a time. Additionally, postgres starts using "genetic algorithms" aka testing random combinations of joins with 12 joins by default (geqo_threshold setting).
I generally agree its better to use database to its fullest, but I would say 8 joins is probably the "limit". Internally at work I've advised teams to try to avoid anything more than 6 joins for "hot-path" queries.
> literally save like 20 seconds in some cases because 1 HUGE query becomes 8 straightforward ones with maximum index usage.
I don’t understand how splitting a query up would have any relationship to index utilization; the planner should trivially pick up on it?
Also are you sure you’re not solving a different problem[0]? Doing joins manually being faster doesn’t smell right, except in the case of data duplication increasing total resultset size substantially
Like the cost of increased network load from not filtering through the join should outweigh anything else in the equation
You can have well-integrated applicative workflows (eg: progress report on a permalink in your front end app), app-restart-proof resumable workflows, and it avoids adding an extra piece of infrastructure.
We use Postgres for that on https://transport.data.gouv.fr (Elixir app which does a fair bit of processing), and it helps.
Not familiar yet with pg_durable though, but I have used or implemented similar solutions and can relate.
> Those numbers also show why the “wealth transfer from India” is mostly fake. India and China were both at a subsistence level. There was no meaningful wealth to transfer.
“Wealth transfer” implies that there’s a pile of money in one place that’s moved to another place. That’s not what happened with India. At first, the EIC was a very profitable middleman. It was like Ticketmaster—it made a profit on a trade monopoly between Indian producers and European customers. The nature of middlemen monopolists is that they get rich through a tax on value creating transactions. But they don’t represent a transfer of wealth from one country to the other.
Say a shipment of tea is worth 100 pounds in India, but 400 pounds to the British. EIC has a monopoly on the transaction. They pay the Indian producer slightly over 100 pounds, and charge the British consumer slightly below 400 pounds. They collect the surplus of 300 pounds. But money isn’t being taken from India! Instead, India’s loss is the lost opportunity to get an higher price for their goods. But British consumers also lost—they were overcharged. The EIC captured the value created by the Britain-India transaction.
When the EIC became a government, they got into the business of wealth extraction. They usurped the Mughals prerogative to levy taxes. But this wasn’t profitable! Within less than 20 years of the Battle of Plessay, the East India Company was in dire financial straights. It couldn’t make royalty payments to England and owed large sums of money to the Bank of England. That’s what precipitated the government takeover of the EIC.
Not an Elon fan, but markets dictate the value, not analyst reports or "fundamentals". The stock is simply worth whatever people will pay for it. The fact that people are paying an implied valuation of 2T for it currently is a strong signal IMO.
Markets dictate the price. The terms "price" and "value" generally have actual meanings as used in financial markets. The idea that nothing can ever be mispriced (defined as price != value) is not really held by anyone serious.
Markets dictate the value empirically, because by definition the price is set at the market, so that's something of a tautology. But markets don't do fundamental analysis on a stock to take a step back and think what is this really worth.
In other words, markets are great at discovering the price at which something will transact, but that's just a function over all price expectation of all market participants.
But each participant can do their own fundamental analysis. This is one of them.
Some participants are better than others at such analyses. It's up to you to think through the ones that get published.
Pricing things differently from the market observed price is how you get alpha.
> The fact that people are paying an implied valuation of 2T for it currently is a strong signal IMO.
Strong signal of what?
You’re mixing the colloquial concepts of price and value, imo. Price is where people who want to sell meet people who want to buy. There are entire industries dedicated to evaluating assets, i.e. assigning them a value, many of which do not have a “price” because they are not for sale. Morningstar is part of one of those industries.
reply