skysight-inc/HackerNews huggingface dataset:
The strong nuclear force, electromagnetic force, and even gravity are strong enough to overwhelm the expansion within individual galaxies and even local groups of galaxies.

In other words the expansion of spacetime very very very slightly tries to shift the atoms of your body apart but we can't even detect it because ordinary forces like chemical (electromagnetic) bonds are exponentially stronger - enough to pull things back where they should be. Actually in the current epoch I'm not sure if the expansion is strong enough to shift an electron by 0.01% of its own width let alone move an atom.

Space is really really big so that tiny amount of expansion adds up over long distances.
Old mice grow young again in study. Can people do the same?
Yep, this here.

I work with a product that sees a massive difference in use between the low end customers and the very highest end of customers. For the low end customers it doesn't matter what your architecture is at all. Could be a single small machine in a closet and it would suffice.

For our large customers it matters 100%. They are doing throughput 4 to 5 orders of magnitude higher than our most basic customers per day. They will push NAS and database performance to the limit. Every time we think "eh, no one is going to do that much" our customers come back and prove us wrong. Databases expand to billions and billions of rows. Query performance falls apart. Design decisions lead to lack of ability of horizontal scaling.

And when the systems get to this size the costs of operating the system add up quickly, and if your competitors choices lead to much lower operational costs, then expect to lose customers to them, especially as your product equalizes in capability, or at least meets their set of needs.
i think he just meant if you didnt reply at all might look like that and since he saw it just put a thanks in to save face for you
The risk of focusing on code and architecture too much is that it will never break. Not because it's very reliable: because you have no users.

Part of being a professional engineer is recognizing that your knowledge is always limited. No matter how much you think about these things, they will always break. Being too careful is as bad as being reckless.

Instead of trying to prevent failure, accept that it's inevitable and make sure you are fast at detecting and fixing.
I don't know why articles are titled like this. it's annoying, though, I'll tell you that

we are finding the exact correct number of galaxies of the exact correct ages; our expectations are wrong, or how we determine what we've found is wrong. generally, our understanding is wrong. not the rest of the entire universe.
Put another way, startups are trying to find a way to exploit a market niche as fast as possible. They happen to use software to do it. They’re (usually) not in the business of engineering.

I say usually because some startups are building new computers, libraries, and software infrastructure and care a lot about things that SV-style startups don’t.

Which means: this isn’t universally true advice. If I’m buying a new computing system from you I’m certainly interested in your tech stack and it will be a key feature.

But if your business is getting people to buy more things they don’t need then yeah, use a batch script and some spreadsheets if that gets you to market faster.
It's funny. I'm working, right now, on a modular SDK that is the "heart" of an iOS app that we've been developing for a couple of years. I've taken functionality that was distributed all over a 30-screen iOS app, and distilled it into a simple-to-use, platform-agnostic SDK. This gives us a "kernel" that drastically improves the flexibility, quality, performance, and aesthetics of the app.

It's a thing of beauty.

And absolutely no one but me, cares.

That's exactly what I want.

I'm a little bit butthurt that no one wants to gaze in adoration at my cool toy, but it's not open-source (as if that would even matter, as I've discovered that no one actually ever seems to look at open-source code). The app will work much better, as a result of the work that I've been doing for the last couple of months.
Something which sounds exactly like the Big Bang Theory to a layman but whose expansion satisfies a different equation.
Beware of www.retune.so – “The Missing Front end to ChatGPT3”
It seems that I may have been scammed.

I asked if retune could extract data about symbols on a drawing, but it was not able to do so.

Instead, it offered to create a tool for me. In order to start with retune, I had to provide it with an OpenAI API key.

The conversation seemed too good to be true and the email address provided, which was example@example.com, raised suspicions.

But one strange thing was it said it might take a couple of days to finish my "project".

After the email address bounced, I was given another email address, multiple times, but it was redacted every time.

I checked my OpenAI API key and it had not been accessed.

I believe that the company is gathering API keys to exploit them in some way, nothing else makes any sense.

The website also lacked customer service links or an "about" page, making it impossible to get any assistance or clarification.

I have cancelled my API key and would advise others to be cautious, as it seems like a scam reminiscent of the early days of cryptocurrency where unscrupulous individuals take advantage of uncertainty and lack of knowledge.
they'd have to navigate the dungeon first. if they do that, then I guess me being arrested is their prize
A New Way to Monitor Blood Flow in the Brain
These heavy handed approaches in the last couple of years makes me wonder what the NSA found out about TikTok. Two consecutive presidents, that held relatively different positions on foreign policy, and government officials at various levels are all pushing to expand this ban. The public sentiment does not agree at all with these bans.

I know that TikTok isn't strictly popular here on Hacker News or on Reddit, but the product is not appreciably different than Vine. The general public loves using TikTok, and this can be see from how it genuinely competes with Youtube in terms of user engagement.

On the other hand, the app hasn't been banned on consumer devices like it was in India. If the national security risk was genuine, I can't imagine the government would be this slow to act. Indian banned the App back in 2020. Some universities have also banned TikTok on their wifi networks.

I personally don't agree with the bans without public evidence of a cybersecruity threat. A company hoarding user data that users are willingly supplying doesn't become a cybersecurity risk just because that company is Chinese. The age group that is currently in college are the biggest users and creators of TikTok, they will use a VPN or switch to data to consume content. Until evidence is transparently release, showing nonconsensual data/OSINT gather, this feels like a political play. Especially since similar data gathering companies are not just allowed to exist, but employed by the US government for their intelligence gathering. Palantir is continuing work with the US government to create a surveillance state, more than what they did to help arrest and deport immigrants crossing the border.

I hope we see some information showing concrete secruity threats from TikTok.
"Cash for care" was a compromise forced through by the Christian Democrats to attempt to roll back long standing daycare policies, but it only ever applied to one and eventually two year olds, and was rolled back heavily as soon as that government fell after one decade.

The majority of the last half century has been characterised by steady expansion of daycare, just like in Sweden.

> that was used by 91% of citizens?

That is a ridiculous exaggeration by omission, given that daycare takeup for the covered group consistently remained relatively fixed, reflecting that in most cases it changed parents behaviour very little.

In 2000, two years after that policy was introduced, 37.1% of the eligible age group was in daycare, by 2005, a majority of the eligible group were in daycare. By the time it was removed for 2 year olds, the number was 78.1%, and today >85% of the originally covered group is in daycare. This steady growth in takeup has closely followed the overall increase in takeup of daycare.

Overall the long term percentage takeup of daycare in Norway has gone up year over year nearly every year since the mid 70's, just like in Sweden, the exception being with lowering of school starting age.

Today, 93.4% children between 1 (after majority of parental leave is over; some extends past one year and so contributes to pulling the 93.4% number down) and 5 go to daycare in Norway according to Statistics Norway.

So the point remains: If it was Sweden's use of day care that has supposedly led to these supposed problems, you'd expect to see the same issues in Norway (half the references were 404's or had no links and no full titles of papers, so I'm see little reason to trust that they've not been equally selective in their treatment of their sources as their convenient failure to address this).
I don't say oil is convenient, I say oil is necessary. Is farming your own food without any fossil fuels possible for you? For me, it is impossible. Not inconvenient, not infeasible, but impossible. I can't afford land to farm on, I can't buy or catch or tend to farm animals to replace tractors, I can't buy or make farm tools that do not come from fossil fuels. Alas, I have to buy food shipped to me using fossil fuels, and farmed using fossil fuels.

If I pay taxes I help subsidize fossil fuels. If I get an EV its manufacturer burned fossil fuels to create it and ship it to me.

Tell me who I can vote for to change this. Tell me how I can eat without using fossil fuels. Tell me how I can work without using fossil fuels. Tell me what choices I can make so that I am not to blame.

There is no such choice. I literally cannot avoid fossil fuels.

Maybe if we could all agree that the fault is indeed with fossil fuel companies, who not only provide oil but also lobby the government to prevent us from moving away from it. Maybe then, we could have the actual change you are clearly so invested in.
Incomplete/unconfirmed data is showing some discrepancies for what our tentative models of the early universe predict. The data could be wrong or misinterpreted, the models could be wrong, incomplete or misinterpreted, or the could be fundamental problems with the very foundations of cosmology. The models we have of early galaxy formation are very incomplete and based on very little data. It's exciting to get data that will discover new things about the early universe and help refine those models.
There’s also a lot of selection bias: that region is the most popular and people remember hearing about problems a lot more than the people who were unaffected but didn’t say anything about it.

I’ve had plenty of instances in us-east-1 for over a decade without downtime other than the 17 minutes in 2011 where they had a network routing issue which kept the entire region running but off of the internet. I never had that with a colo - power outages & backhoes - but several came close.

For me, I’d tend to focus the question on how screwed you are if something goes down. You can save a ton of money for a bandwidth-heavy service if you use a colo so it’d really be a question of how easy it is to make it redundant (short outage) and rebuild (long outage or permanent equipment failure).
Are there any interesting things you know not mentioned in the article which you want to add here? (I’m curious to hear more)
For me, this boils down to a question of "what set of problems do you want to solve?" and "what set of problems do you want the system to solve for you?"

To this end, I am generally a monorepo proponent. The problems with "what gets built" and how do you do versioning of the components" for the systems that I work on is an easier set of problems to solve than "how do I ensure that I don't break anything else when I update this method?" and "if I do break something when I update the method, where is everything that needs to change?"

I've had projects that were fractured across half a dozen repos where libraries were versioned and tagged and and deployed, and then the next down stream was updated to use the newly tagged version... and something broke. This was especially bad when the "something broke" was part of another team's code or it had been thrown over a wall. A bunch of changes, many PRs - some of which are just updating a version to pull from the artifact repo.

When things were updated, I took the opportunity to move all of those projects into one monorepo and I only had one PR to review - that passed all the tests for all of the projects contained within the monorepo.

Yes, deployments and tagging and the "well, just because you reved X to 2.3.0 doesn't mean that Y is at 2.3.0 too" (strict semver can get a bit on the messy side).

It's a question of which problems do you want to solve. I tend to find that me solving the "how do I set up the ci file and coordinate version numbering" is an easier problem to solve than "all these builds need to be updated in a bunch of different repos and one of them breaks."
I think it's deliberate and it could be quite harmful. Someone who knew your real name and was thinking of messaging you out of work could have thought you'd be lonely or stressed and seen it and figured you were feeling fine, and not bothered to reach out. This could have been the difference between a strong friendship and falling completely out of touch. They shouldn't mess with people like that! The person doing it deliberately (if I'm right) probably didn't think of the harm. If it was accidental they should have deleted it right away.

Best of luck, both in finding a new job and maintaining connections/friendships from this job! I have seen you on HN a lot and am surprised to see you let go. Chalk that up to the halo effect and years of corporate culture programming me to think that productive people are seldom let go.
Covered in the article.
> These tools that were never designed for devops in the first place.

No. Git was specifically developed to manage the Linux kernel project, a famous example of a monorepo.

Every instance of polyrepo architecture I have seen in the wild, comes with some kind of bolt on system which emulates a monorepo. Such as: a top-level manifest file which pins the versions of every repo to a known-good value. With the understanding that if you were to pick any other combination of versions, You Are On Your Own.

My current company does this and it's quite unpleasant. I call it "monorepo as a service".
Theres nothing massively wrong with it, it's a perfectly plausible model.

The one thing that isn't particularly nice is that spheres have intrinsic curvature, essentially if you draw two parallel lines on a sphere they will eventually touch. We can go and look at astronomical data and see if the universe has any intrinsic curvature that we can see.

People did this and it turns out that from all the astronomical data we have the universe looks incredibly, spectacularly flat. No curvature at all that we can detect. This doesn't mean it isn't a sphere, but it means that if it is a sphere it's a really big one. Much much bigger than the observable universe.
I have my doubts about the mono repo approach. From the top of my head:

1. It might increase the complexity of other process on that repo: CI/CD configuration, makefiles, branching strategies, codeowners etc

2. The versioning might lose its meaning

3. Blast radius in case of screwing things up accidentally.

I personally split repositories based on responsabilities: here the code base, here the iac, here the configuration, here the manifests. Always using a standard and predefined naming convention for the repository names. That being said, as always, it depends. I might embrace the monorepo if the context demands it and it has been properly discussed and evaluated.
The Solution is very simple:

1. Scrap everything you have done so far and start over.

2. Use tried and tested engineering principles as basis for your development philosophy (such as "mechanism, not policy" or "Keep It Simple Stupid").

3. Choose the right target audience. The target audience of the FOSS-Desktop are neither car entertainment systems, nor Android consumer users that potentially download malware everyday. Your target audience are power users and developers that know what they are doing. If you don't agree, go work for a car manufacturer, work as an Android developer or do something else, just stay away from the FOSS-Desktop.

4. Do what developers and power users need! Just some examples: use simple and stable interfaces, use non-opaque low-level abstractions, standardize often used functionality, avoid redundant standards, don't litter my pstree with pointless daemons, use existing mechanism provided by the OS, use clear text for low bandwidth IPC, keep dependency trees as small as possible, keep build dependencies as small as possible, look at Plan9 as inspiration instead of Windows and MacOS.
I looked into it, its not 'a bit'. You'll need to stock up on diapers.
I am not too worried about Russian submarines meddling with the undersea cables between england and scotland…
Was that a Snowden revelation? Isnt it the whole point of the five eyes to skip over local law?
Off topic and probably another rule: Insane Clown Posse agrees with you.

"Fuckin' magnets, how do they work?" From their hit single, "Miracles," on a Psychopathic Records.
https://m.youtube.com/watch?v=_-agl0pOQfs
If the ops engi is trying to do a favor, that favor would be removing access. Under no circumstances should someone fake being another employee. They shouldn't even have the access to do so. This smells like bad security practices.
Could it be that submodules are underused?
https://en.wikipedia.org/wiki/Eternal_inflation
I'm surprised TikTok was allowed in the first place, it sure isn't allowed on my work phone with is locked down to the point of driving me batty with how useless it is.
Their fault for sending the clerics in before the rogue.
I don't get why the underlying problem is not even being discussed here at all. Any attempt to fix the system will have to increase investment in both training and drug research.

This will be a large investment (if doubling the training budget produced double the graduates that would not be enough), and will NOT bear fruit until those people actually graduate, which is 6 years minimum, and mostly 10 years away. So for 10 years, it means paying through taxes while getting minimum to no improvements in return. Furthermore, such a large increase is not possible at short notice, even if the money is available, so it will take more than 10 years time.

For research one might take profit margins of large pharma as an indicator: a fully nationalized, but equally capable, pharma research system would cost some 15% less, assuming nationalizing introduces zero inefficiencies. BUT that money would have to come from taxpayers directly through the government budget.

And nobody is looking for 15% reduction in drugs costs. That just won't move the needle enough. So in reality the government would have to increase the drug research budget to make drugs cheap.

Failing to do this will mean medicine becomes less accessible to people, regardless of whether we switch to a single payer system or not.

So let's get real here: we will fail to do this, and it will get worse.
yes, some part of aws somewhere is always online.

fully functional? 7.12.2021 alone was enough to kill that statement for the next few years.
as pointed out in the source

> although it is clear in some places that inaccuracies and Ibn Fadlan's own
prejudices have slanted the account to some extent.

Seems a bit silly to believe she volunteered for that while also stating that there's "no way to know anything clearly" (except possibly the most absurd part?)
I suspect that one of a big untold reason why we transitioning ICE to EV is because we don't want to pay for monarchy countries.
No. US patent law is quite explicit about that. First to publish wins.

Deliberately infringing a patent can trigger punitive (3x) damages. "Convergent evolution" could be a defence against that kind of claim. That's a reason big-co lawyers tell devs to NOT read other companies patents.
I also prefer this way.

People sometimes complain that software engineering isn't real engineering then push back on components like these, preferring hairball duct tape for short-term business reasons, which isn't exactly the quality that German and Japanese engineering have.
This is a really good thing, and having been through this in other Google projects, a sincere congratulations to the folks who demonstrated the tenacity to keep pushing forward despite both I'm sure a lot of genuine hard questions being asked, and a lot of fud. This outcome will be good for users in the long run.
I absolutely notice if my monitor runs at 60hz for whatever reason instead of 144hz, even while just doing desktop tasks. Have you used a 144hz screen for any significant period of time?
Yes. If any of the constants were different, or the formula were different, we'd see it.
Indeed, but the man hours involved was quite surprising to me. Some work was per platform, some per cellular provider, some per country, etc.

Also it's less confusing for users if they can say "if you use signal, it's encrypted", unless of the confusing and hard to support decision tree, which is made doubly confusing because Signal uses phone numbers are part of your identity.
Shoving words into someone's mouth is no favor.
I question the implication of this common assertion - how does knowing history change the repetitive nature and outcomes of human systems?
Let me get this straight: you believe that Node's tooling is better than Golang's tooling?

The entire Node ecosystem is commonly described as a dumpster fire.
> I've worked in large polyrepo environments. By the time you get big enough that you have internal libraries that depend on other internal libraries, debugging becomes too much like solving a murder mystery. In particular, on more than one occasion I had a stacktrace that was impossible with the code that should have been running. A properly-configured monorepo basically makes that problem disappear.

On the contrary, a monorepo makes it impossible because you can't ever check out what was actually deployed. If what was running at the time was two different versions of the same internal library in service A and service B, that sucks but if you have separate checkouts for service A and service B then it sucks less than if you're trying to look at two different versions of parts of the same monorepo at the same time.
that's a great one as well!
Bitter Lesson 2.0 for Robotics
They will probably end up requiring a buy of $116k/unit headsets from LockMartRayBoMageddon which will then be subcontracted to Microsoft
Tuxedo Computers sells the Pulse 15 with a centered keyboard, 1440p 165Hz screen, and AMD CPU+iGPU. Pretty nice laptop, except the integrated microphone is a bit shit.
Dietary Cholesterol and the Lack of Evidence in Cardiovascular Disease (2018)
1. Often it ends up being easier

2. Versioning becomes easier

3. Blast radius is similar but cleanup is easier
How do you know what they’re saying as you after you’re locked out? Like, what if they’re sending messages as you to outside vendors, to leverage existing relationships?
Javice and the data science professor create fake customers