skysight-inc/HackerNews huggingface dataset:
"Perspective is worth 80 IQ points"

By trying to obtain a grander perspective and awareness of the scale and scope of the universe, one sees many limitations of our own species :)

Perhaps, one such limitation is an inability to define what really is meant by "intelligence".

Relevant example - inventing the atomic bomb (result of intelligence), using the atomic bomb (result of same "intelligence"?). There are many such examples, showcasing how confused/irrational members of the species can get.

Maybe it is just wiser to sidestep the question altogether, and ask a better question, something that can be answered.

In my opinion, the problem stems from trying to get an extremely generic definition capturing performance in all sorts of disparate behaviors and activities.
Stop thinking and do it :)
That's not what happened here. We're talking about an outage that was resolved days ago, long before this thread went up.
People have literally tried to hack together an agent on top of GTP-4 and given it an explicit goal of "kill all humans" for the lulz (ChaosGPT). I don't think that particular case is going anywhere, but assuming that nothing roughly GPT-shaped can acquire harmful goals seems naive.
> we actually can't state with 100% confidence that exercise is good for your health

Doubt. It depends what definition you use for "health" but we know for a fact that a sedentary lifestyle has negative effects and that an active lifestyle has positive effects. Those assertions are indisputable.
Ah the lengths they will go for our safety.
https://archive.is/Ji7tB
At this point, fusion feels more likely than carbon capture tech. It's a shame if we stop Atlantic shipping routes that pollute a ton of particulate, the earth will heat up even faster.

One thing that I like to keep in the back of my head as a fun, unrealistic comfort is Alien stuff. IE some of the "whistleblowers" that have written how there's aliens under the sea, in what appears to boil down to organic automata, purpose built for the task, piloting vehicles that are built and broken down purpose built for a task, with a power source that seems near infinite.

The description of them as zoo keepers, "abducting" people in areas where disease or bad health is rampant as some kind of "population check". It's oddly comforting because if they wanted to destroy humanity, they could, and one must ask why they haven't yet and why they would be simply watching.

Hell maybe they'll save us all but in the mean time, I need to figure out how to grow potatoes, squash, and greens.
> a drug like donanemab that has better results the earlier you start it.

Do you think there will ever be a point where Donanemab or similar drugs will be recommended for all people after a certain age?

If I am thinking of the same medication, doesn't it have pretty nasty side-effects -- 30% chance of brain bleeding, right?

It's tough, because after a certain age, I think it would be worth the risks (in my non-medical professional opinion), but I am not sure if that is how medicine works in practice. I mean, you wouldn't want to give one medicine for a condition that he or she might never end up getting, but you probably also do not want to wait until it's too late.

I am just hoping that we find some kind of treatment in our lifetimes.
Sprints are effective for delegation. It is a way to communicate what to work on, the order and how long tasks are expected to take. If a tool like JIRA is used more systematically, we can just document and communicate many things thru it.

Plus we get a statistical sense of progress after a few sprints. Some people prefer visuals like Gantt charts.

It is best to encourage individuals to plan their tasks in a tool. Some tool is critical to a sprint, it is a way to get some writing reps also. Others can read and provide feedback. Post-its on walls is not effective sprint planning.
Reminds me of some Lotus Notes folklore. Apparently they used to use timestamps with a resolution of 1 second as unique IDs for things. When there was a collision, they would just add 1 second. Eventually, you'd end up with items being in the future because there would be so many collisions.
This is a press release article…
Well, to decide whether "sprints" are a good thing or not, you have to consider the history, which is mostly centered around the alternatives.

"In the Beginning, there was Waterfall" -- prior to the era of agile practices, waterfall was king: first, gather requirements, then, design a system based upon those, then implement that system, then test it, then deploy it, then maintain it. And write volumes and volumes of detailed documentation about all of these steps.

While there is nothing really wrong with waterfall per se, it tended to annoy people greatly, due to delivering irrelevant software and tons of irrelevant paperwork in many (if not most) situations. Because unless you're, like, building a moon landing guidance system, "the business" tends to change too much between the requirements and deployment phases. And/or: the "requirements" people were simply not very good at their jobs. In any case, pretty much everyone was unhappy with the end results.

So, at some point, there was the "agile manifesto" movement, which tried to fix this from the side of both the "business" (which felt it was spending too much money all the time) and the "developers" (which felt they were doing pointless work all the time). The four main points of the movement were and remain:

(1) Individuals and interactions over processes and tools
(2) Working software over comprehensive documentation
(3) Customer collaboration over contract negotiation
(4) Responding to change over following a plan

So, right away, most of your reservations about "sprints" seem to be negated by principle #1: Trainers, books, seminars and rigid CI/CD are not prescribed by capital-A-Agile at all. It's about you, your team, and what you decide to do. Of course, this may very well mean you should look for a different team, but that can happen due to many, may other reasons.

"Artificial deadlines" are, in my experience, mostly a commercial issue. A "sprint" is always a fixed amount of time, to be spent on development. If malfunctions and associated maintenance take time away from a "sprint", that should be covered by a support/maintenance agreement. If the same people work on both development and maintenance, the former should be paused while the latter takes place. So, a 2-week "sprint" may very well take 3 or 4 weeks, if interruptions take place.

This takes some adjustments in contracts, sales, etc. But I can assure you, that a "2 week sprint of uninterrupted development time" coupled with a "maintenance agreement that extends any development sprint by the time required for personnel to fix and re-focus" works quite well. Sure, some sprints will end up taking many weeks but that's all time that's paid for, and nobody will object to payment in the end, provided all is agreed upon in advance and backed by time-sheets afterwards.
Right. Check out the new Netflix documentary "Unknown: Killer Drones". Basically former soldiers running military tech companies with the experience of losing their friends in battle are looking at how DeepMind's AIs are undefeatable at Star Craft II, Go, and pretty much every game they train it for. And already testing plugging that type of thing into drones and jets.

And now DeepMind wants to combine the language-based fairly general purpose reasoning ability of something like GPT with the superhuman strategic prowess of AlphaStar/AlphaZero/etc.

At the latest big keynote Nvidia touted the fact that they have accelerated AI by a factor of one million over the last decade, and project that they will do so again in the next decade.

Humans will not be able to compete at all, and even putting them in the decision loop will mean immediate failure. Human thought and action will "appear" to be so slow that it is essentially frozen compared to the operating speed of these systems.
Figuring out the connection between seeing someone stepping on a rake and immediately after getting smacked in the head seems much simpler than knowing about the .com bubble and from that alone managing to avoid the same mistakes decades later.

It's easy to call out the similarities now, but I doubt it's easy to avoid the mistakes in the situation.
That's fine, but when a request comes in referencing only a hash and not an id (because you're not leaking ids to clients), how do you get the id?
That’s what I’m building :)

https://zendo.blog
> The whole point of opening up to trade with China was the hope that the exposure would have influence on their people and that democratic ideas would win out in the end.

That was one of the many really terrible ideas that we've had. In the US we say "It's the Economy, Stupid" to represent the idea that, when the economy is doing well, people are happy with the government. And then we helped give China decades of incredible economic growth, but somehow expected that the result would be Chinese citizens being unhappy with their government?!
Season 1 was good. Season 2...not so much.
In practice I usually see that when developers finish tasks early, then they don't just sit around doing nothing for the remaining 2-3 days, they pick up new tasks right away. This means there's never a clean "end" to the sprint, it basically just turns into Kanban with scrum ceremonies.

It's quite difficult to get an org comfortable with developers having so much downtime at the end of a sprint where they can spend those days focusing on other stuff.
I'm not. The paper specifically deals with language models in particular. Memory is just dynamically inserted context
Models can breakdown at huge scales because they introduce other non-representative factors or nonlinear responses.

Sending an astronaut to the center of the Sun and concluding their death is from radiation would be a pretty bad model.

Hitting a person with a car would be a pretty bad model for a fly landing on them.

The first model is bad because the sun is doing more than just exposing them to radiation.

The second model is bad because there's a nonlinear response to force applied to a human body.
My wife pointed out and I feel dumb for not realizing it because I know this myself, you never heat baby food much past 30 seconds, certainly not for 3 minutes at highest setting. Babies generally eat baby food at room temperature to body temperature, and anything outside that is considered extreme to a baby's sensitive nervous system, not to mention you wouldn't want to risk lava spots that might burn their mouths. That adds a rather unrealistic element to the study.

It's far more likely to effect people eating microwave dinners, reheating food/meals in plastic containers, and even then those are different tougher plastics, that said it might be reason enough to just invest in glass containers for food storage.
I find it works well in two situations:

1. Protecting a software team in a non-software organization. In this situation the team has no voice in prioritizing work, is under constant pressure to deliver, and is generally viewed as a cost-centre by leadership.

Taking a lead role and introducing an agile/scrum-like process is a way to deflect unreasonable demands off of the team. The goal is to convince leadership that deadlines aren't as important as progress. Demonstrating regular progress and having check-ins is a way to console the existing leadership and build trust with them while the team gets breathing room to address their concerns and learn to prioritize what needs doing with what users want to be done.

Don't get too invested in it. The incumbent leadership might try to wrest control of the process back from the development team. If they get involved you'll notice more meetings, new job roles, and presentations with charts and diagrams explaining how the scrum/agile process works. This is plain old Taylorist micro-management sneaking its way back in. Be prepared to give up on agile/scrum before it gets to this point or make sure that your team is in control of the process and not external stakeholders.

2. Establishing a new team with customers in the absence of management. In this situation the customer is basically your manager. And they will want deadlines because money. Similar to the first situation, agile/scrum here is about managing expectations and getting parties on two sides with different priorities to work together and trust one another. If you can build up that trust you can ease off on the agile/scrum stuff as needed.

In every case the important part is that the development team, the people writing the software, are in control of prioritizing what work gets done and how it gets done. As soon as you have diagrams and presentations and several layers of "managers" involved in directing a software team you've entered into the Agile Industrial Complex and have dropped the ball.

Caveats: you will find that some developers will refuse to work with customers. They do not want to co-operate with management. They only want to write code and view any process to manage work as a waste of time. The important thing to remind them of is that you don't need to use any of the scrum/kanban/whatever processes forever. The goal is to get management off your backs by showing them your team can deliver results by shipping stuff on a regular cadence. Once things get into place you can change the process to whatever works for your team as needed. That's the whole point of being "agile." No need to cargo-cult rituals for the sake of performing work. Do it until you get the trust you need to get back to work.
It's 64 bit on 64 systems. In the world of hard realtime applications there's still a huge armada of systems out there in the field running on 32 bit (think motion control, CNC machines, industrial robotics). If you're developing software that's concerned with this kind of precision, you might find yourself confronted with such "outdated" systems more often, than not.

Also see https://news.ycombinator.com/item?id=36814762
The article uses the term "Controlled Environment Agriculture" (CEA), which seems like a better descriptor than vertical farming, which is pretty narrow in scope and a bit solarpunk in vision. The nice thing about the term Controlled Environment Agriculture is that it can cover a wide spectrum of enhanced farming techniques, including a plain old greenhouse. Then it becomes a question of which type of CEA is most appropriate for an area. Even the most crowded cities tend to have areas of much lower density nearby that make the high-rise farm idea not a good use of resources. But boring old warehouse space used to create a controlled or semi-controlled growing environment might work in some cases, especially for higher value, fussy plants. Probably will never make sense for things like iceberg lettuce.
People keep saying they need a light and fast distro - no systemd, no glibc - but it breaks a lot of other software. So, you need to be prepared to patch a lot of stuff, and build packages from source.

Personally, I would love more of them to consider FreeBSD. It's got all of those features, a linux compatibility layer if necessary, a more permissive license, etc. I'd just love to see a lot more developers helping over there.
If they genuinely could tell it was not being actively used (or really, even if they wanted to limit to x hours whether used or not and that's what's going on here) why not just disconnect it, why resort to emailing the user?

It sort of implies that's not possible, but really? I can't imagine how you could be doing the routing, monitoring the connection, and yet unable to terminate it?
FCC Issues Warnings for Allowing Illegal Radio Broadcasts
I see. Have you considered eliminating this configuration from your offering? It sounds like the terminology could confuse people, and it may be the case that they're assuming that a host isn't really what it is (a single host). This kind of thing is difficult for those seeking to build managed services, because I think people expect you to provide offerings that can't harm them when the cause is related to the service they're paying for and it's difficult to figure out which sharp objects they understand and which ones they don't. People should know better, but if they did would they need you?

If this sounds ludicrous, then I think I probably don't understand who Fly.io wants to be and that's okay. If I don't understand, however, you may want to take a look at your image and messaging to potentially recalibrate what kind of customers you're attracting.
AI and Microdirectives
Is John Romero more active publicly than Carmack?
Y'all remember Macromedia Dreamweaver?

Nothing against this particular project, but how many times are we going to recreate a wysiwyg cms. There must be hundreds at this point.
"Oh you do not understand it was complicated"? I think what you are saying is just creating another excuse to justify the bombing. As complex as it is at the end of the day you are making a decision to nuke a nation. Do you think Russia should have used it on Ukraine by now?

I think it is a fact of life that atrocities happen during war. Just admit it and say that this was one of them. Do not give me the "This was for the betterment of the world" BS.
All this says is that the interection with twitter is larger than it is with threads. By this logic Instagram must be dead and burried given that the last HN post from instagram.com was 37 days ago.

https://news.ycombinator.com/from?site=instagram.com
Dang once mentioned that the actual HN codebase is full of YC business code that would be very difficult to extricate - and that parts of it like the spam filters and flamewar detector they want to keep secret to prevent people from gaming the system. Also that he just doesn't have time to do it.

As far as "secret sauce" goes, the sauce is that the mods actively upweigh, downweigh and filter user accounts all the time. Trying to reverse engineer a working algorithm from this site's behavior is a fool's errand.
Oh good, a tertiary effect of climate change is we're going to have to trash all the plastics and electronics that were made for normal temperatures.
I live in Austria, in a building without AC, it's currently 33°C in my apartment and my iPhone 14 Pro refuses to charge to more than 80% due to an overheating warning.
Google Loon or whatever they called the stratospheric balloons carrying solar powered cell/wifi base stations that made their way around the earth with the Jetstream or w/e used a bladder in the balloon that was inflated/deflated with ambient air.
Similar to a ship taking/releasing ballast water in ballast tanks.
Coming soon: How Turborepo is porting from Rust to Zig/whatever hottest language is to have on resume next year

These blog posts make me laugh. Pretty sure they could achieve whatever they are doing with any language, heck even PHP would probably work. Just not cool though is it.
I’m not entirely sure of that, and it will take some effort to follow some of the proofs, but it will be worthwhile. I think this would be a good book for a technically-oriented book club to discuss, taking on one proof a month.
Why not use the lingua franca tools of the university website.
When OP said "social media platform"
Show HN: Qwokka – see what's great on Netflix
What’s causing big media company disruption?
I really regret how hard of a hold the Dunning-Kruger report has had on our generation. Worse, it seems every reference trying to point out that it is, in fact, not saying what people think it says just reinforces folks believe that it says what they want it to say. :(
Odin looks extremely appealing to me, but I am quite sad about the lack of methods, or more specifically, lack of guarantees about "dot-autocomplete" support in mainstream code editors. But I do think methods make code more concise and readable too ( object_verb(obj) vs. obj.verb() ). They are syntactic sugar worth having.

In 2023, tooling is at the point where RTFM is secondary for mainstream lang libraries (TFM being embedded into the editor in intelligent ways). I will not go back.
The benefit to the developer is that they're a delivery cadence agreed with people outside the team so you don't have to deal with constant "are we there yet" and context switching. Think of the sprint as a tool in the toolbox for managing up/out.

You have to think of Scrum as a self-defence: without something like it, the failure mode is the death-march.

> Overcomplication, with an entire industry of trainers, books, and seminars evolving around it.

That's inevitable with anything successful, though. It doesn't have to be complicated: https://scrumguides.org/scrum-guide.html should be all you need.

> Over time, sprint discipline often deteriorates or transforms into something less Agile.

That's a different problem.

> Lack of relevance for teams practicing CI/CD

This strongly depends on what your definition of done is. I've seen teams who think they're doing CI/CD who just plough features into a "next release" branch that only actually goes out to production once a month, or less. This goes exactly as well as you would expect.

But even in a continuous delivery world, I can still see value in "let's see if we can get X done in the next two weeks" where X takes several deliveries to get out of the door. Theming the work helps reduce context switching within the team.

> The creation of artificial deadlines leading to overtime, burnout, and, eventually, high staff turnover.

If that's happening, it's not the fault of the sprint. The work scheduled into a sprint shouldn't exceed what's actually achievable by the team, without overtime or burnout. If people are regularly and repeatedly burning the midnight oil to hit sprint goals, that's a strong signal that there's something wrong elsewhere in the organisation that needs fixing.

> Inability to handle reality. Interruptions and unforeseen tasks will occur.

That's a weakness, but not fatal. Sprint planning should allow for enough flex to cover some unexpected work. You're right that WIP limits could handle it, but with a sprint at least in theory the idea would be that when something that bad comes up, it forces a conversation with the product owner to scrap the sprint and start a new one. The danger in only handling it with WIP limits is that that conversation might not happen.

I do think the current Scrum Guide has made a major error in characterising the Sprint Goal as a "commitment". For several years it was a "forecast" which I think was far more honest and less likely to prompt abuse.
What a silly email from a CEO.
Wolfi-Act: Dynamic GitHub Actions from Wolfi Packages
Ah, OK. I would just hit ctrl-e and move on, but that's just me.
It's also much easier to set up debugging tools when necessary.
I think it was just natural approach while using Github
I was 34 when I emigrated to get away from all that nonsense.

It's not been easy, but it has been worth it.
I like some aspects of it, mostly the ability to say, when someone asks for something to be done Right Now, "here are the things I'm committed to for the next two weeks. Which of them should I not do to make room for this new priority?"

I do NOT like the idea of a hard beginning/end of sprint, it's a pipeline stall.

I generally like to have something I'm planning, something I'm working on, and something I'm working through review on. If I have to be 100% delivered at the end of the sprint that means I have to budget to be finished with all work and just be sitting around herding PRs the last 2-3 working days.

We don't do sprint planning until the first day of the new sprint so I can't really start speculatively executing on next sprint. So I usually overcommit a bit just so I will have stuff in progress at the end of the sprint, and then just eat the PM stinkeye when we don't burn it all down.
Not necessarily. It could take longer because the original estimate was based on incomplete or invalid assumptions.
We use it in our company to provision all our cloud resources. Granted, you can't create app registrations and such with it (yet) like you mentioned, and there are rough spots, but I think that is quite far from "not very useful".