skysight-inc/HackerNews huggingface dataset:
Adrenaline is good for gaming!… I bet?

If you have it going 3600rpm for 60hz uh… θ axis refresh rate (?), you have a pretty tough monitor. Now I’m wondering if you could mount it to 2 really fast linear actuators perpendicularly attached each other. One connected to the desk vertically, and the other fixed to it, with its business end mounted to the monitor.

Now (considering the monitor doesn’t explode from the inertia) you could tile an area larger than the monitor itself. Could even adjust on the fly, so you can drag a window off the screen and it just starts vibrating more and more violently.
Nationalistic flamewar will get you banned here, regardless of which country you have a problem with.

Please don't post like this again.

https://news.ycombinator.com/newsguidelines.html
Exactly. When a market is too busy, it just feels like your being pushed on out by the crowd.
With a healthy dose of AG chemicals!
Hylang, a Lisp dialect embedded in Python
We are going to end up with an ap with very low power every 400sqft or something the way this is going.
I do the same. Given that you didn't mention git-absorb[1], I wonder if you've tried it. If not, you might be very happy to discover it.

[1]: https://github.com/tummychow/git-absorb
In this model of what pay means, nobody making anything pays for anything. I know that's a reductive argument but really it mistakes the relationship of input costs, fixed costs, declared rainfall, and price in the market.

In Australia water has financial value as an asset class and is bought and sold, in a futures model as well as at time of use (irrigation)

I just think you're wrong on so many levels. Only primary mining can be said to not pay for anything in this model and they pay rent and royalties and other costs.
The build events track the files that were changed that triggered the build, along with a load of other stats such as free memory, whether docker was running, etc.

I took a selection of builds that were triggered by the same code module (one that frequently changes to provide enough data) and compared models on just that, finding the same results.

This feels as close as you could get for an apples-to-apples comparison, so I'm quite confident these figures are (within statistical bounds of the dataset) correct!
I dunno…leveraging retrospect is often useful.
> WFH is effectively work from anywhere.

Great if your company allows it, but the “working vacation” thing has been either discourage or disallowed at every remote job I’ve had due to past abuse.

Some jobs can handle truly asynchronous work and some people can be responsible about getting their work done away from home, but for every 1 employee who was pulling it off well we had 3-5 more who were just writing short responses in Slack and to emails to pretend they weren’t actually on vacation. Ruined it quickly for everyone.

Lately I try to look for jobs at smaller companies where everyone can be trusted and there isn’t room for people to get away with those games. Seems much more likely to find more WFH freedom in those environments.
Shallow nationalistic comments are indeed the opposite of what we want here, but please don't start a flamewar about it yourself—that just makes everything worse.

"Eschew flamebait. Avoid generic tangents."

https://news.ycombinator.com/newsguidelines.html
The Hofmann Wobble and the problem of historical memory
Well, that's assuming a very specific, and stale, development direction; I think we would have seen a more native and natural migration to something very macOSX like. Sure, not exactly macOSX as we know it today, but something that we would have used and appreciated as much as what we now have.

What made OpenStep so useful was that it was immediately _available_, but imagine if it was used as a source for tech to be added to the continuing A/UX development, instead of basically being Step One.
Somewhat off topic, but thank you for putting into code what has been floating around in my imagination since high school. I haven't tested your project yet, but I really do hope that AI assisted roleplaying becomes a mainstay in the game development world. I got a taste when toying around with AI dungeon, and if this isn't the the next step in meaningful interactive storytelling, then I don't know what is.
The thing that makes Gentoo fantastic is the fact that it's designed from the ground up to make it easy and maintainable to add the one little tweak you want for your system. In all the other distros I've tried (all the major ones, many of the minor ones), they tend to work better out of the box, but straying from the beaten path results in a flogging like no other. A tuned Gentoo system just works™, whatever "just working" means for you personally. That might be a python 2to3 name collision when Arch decides to overwrite upstream, or a system-critical latency issue when SystemD does too much unnecessary garbage in kernel mode, or whatever, but all of its flaws aside I'm a very, very happy Gentoo user.

Upstream binary packages are just another extension of that freedom. You already had binary versions available of a few major projects (or could roll your own build server), but making more of them easily available allows a lot more people to reap those benefits without having to worry about the huge time sink of building every little thing. If you need more flexibility (patches, use flags, ...) for a given package, that's still available and easy to maintain. This is a huge win.
I cannot grasp that at all.

To rebase I take your patches, apply them, then I apply my patches, fixing any trip ups. You "got in" first, so I get to do the work.

It seems simple to me - far more than hoping merges do what we both meant.

Conceptually, it's patches all the way down - anything else is to me suspect ... might be me not being big brained enough :-)
It's against the site guidelines to post like this, so please don't.

https://news.ycombinator.com/newsguidelines.html
Obsidian is one of a very few pieces of software I feel very passionate about. The devs are incredibly dedicated, and the community is awesome.

Amazing product.
Actual title: Why large companies and fast-moving startups are banning merge commits

I love that title.
standing ovation from me, that was just stellar: not only in the actual content but I found the presentation style really engaging, also

I literally cannot imagine the amount of late nights in the lab grinding through all that deobfuscation and side-channel attacks
Ah yes, that would be it. Thanks! I threwa quick C++ program together to do something similar using FFMPEG.
You can basically achieve that with a rebase then merge with --no-ff. You can then just bisect etc with "first-parent" to see the big chunks as they're landed.
A business in Argentina is successfully cloning horses and dogs
Been a happy customer since 2018! Thank you so much for making it.
Nationalistic flamewar will get you banned here, regardless of which country you have a problem with, so please don't post like this to HN.

https://news.ycombinator.com/newsguidelines.html
> Velcro" wasn't a common word, and was not short for "hook and loop" when the company trademarked it. They coined the term.

You're arguing against a claim I didn't make. I simply said it's an abbreviation for a French phrase (the inventor was a French speaking swiss). Contractions of this sort are more common in French than straight acronyms, which tend to be more common in English. I didn't say it was some pre-existing word.
Years ago I lived on the edge of a violent area in a big city. People were sometimes shot and killed near my apartment, and I often heard gunfire. But I agree -- no one ever bothered me, and after some initial hesitation I felt fine. It was really gang members with guns shooting each other.
Ask HN: Data Scientists, what are the biggest problems you're facing today?
Was speaking to a friend starting a Data Science master's and he asked me this question.

For content, currently working at FAANG, here's what I see:

1. Sharing of code is a pain. Keeping code updated is a pain. I've only been on a single team that uses Git in a decade. And even then, it wasn't really used.

2. Data quality is awful. We are constantly working with other teams to get it fixed, no one really cares but we have to deal with the consequences.

3. Most people want to work on cool LLM projects but there are too many internal blockers. (We don't have access to openAI APIs, we don't have good GPUs to run models in our dev environment, the few models that run on our underpowered GPUs are bad)

4. Thankfully not a problem for me but the hiring market is insane right now.
It sounds like you're more describing a stacked PR workflow. I achieve the same thing using stacked PRs and can still have a bunch of the "fix stuff" intermediate commits that get squashed away, because who can really predict whether everything will pass CI in the first attempt. :)
This is a complete disaster.

On the other hand, are there any companies focusing on tuning llm or plugins to help with legal research and verification of research? Is that even possible?

The scale and size of the law really does necessitate that these tools exist. Especially since citizens are expected to know the law.
Always wait for Microsoft's 'Version 3' of anything before you waste any of your money on it.
I totally agree with your suggestion, and we (I am the author of this post) did spot-check the performance for a few common tasks first.

We ended up collecting all this data partly to compare machine-to-machine, but also because we want historical data on developer build times and a continual measure of how the builds are performing so we can catch regressions. We quite frequently tweak the architecture of our codebase to make builds more performant when we see the build times go up.

Glad you enjoyed the post, though!
Breathable air is pretty valuable, at least for me. And it's definitely not that scarce on this planet.
Employment laws not negotiable by design. One reason is so an employer cannot use their collective power against the individual worker.

An employment contract is not a regular contract and can only be made according to rules otherwise it void and the court will find out the real nature of the contract for you. Even in the US employment contracts mention that all dispositions are valid only when not in conflict with law. The same happens in Europe.

I have a relative who is a work inspector and one case she always points out is the non compete or non disclosure clauses. She says if the contract does not give an obvious compensation for those clauses they will always be voided if tested in court, regardless of both parties having signed them. The threat power often remains though, because people are afraid of falling into such clauses so they self comply without any reason for it. I had work contracts for a developer work where it basically stated I could not have a blog without approval. I found it ridiculous and knew it was likely unenforceable but the tick stays in your head.
> The fact that rebase would ever be preferred over merge just shows how bad Git really is under the covers. It's insane that everyone is re-writing their development history to avoid issues with their source control system.

It's local history that one rewrites, so there's nothing "insane" about it. What your comment does is expose your lack of understanding of this matter.

> We're all suffering that Mercurial lost the war. Of course, even Mercurial isn't perfect. Why did we stop innovating on source control systems a decade ago?

Mercurial supports rebasing and history rewriting just fine.
if json and xml files become database tables we can get rid of everything else
I'm a firm believer and practitioner of the 'inbox zero' method of email management. Naming this inbox helper/organizer the same may confuse people. Why did you choose that name? Seems a disservice to the method you're trying to promote.
It's worth noting that PrivacyTests tests default configurations. If a browser has a good suite of privacy features but doesn't have them on by default, they'll score low on the benchmark.

Firefox, for example, can be hardened very well with options and extensions, but has many bad defaults (like Google default search with search suggestions on).

The site is all baseline, not potential. Not peak potential, not press a couple buttons potential.
oh my! same here, and more importantly it was thanks to you! thank you sir.
This is outrageous and ridiculous.

Cool, don't use my code if you're in Europe or within Europe.

We will need amended licensing for denying use within Europe.
Most developers I've worked with think of Git as a CLI front-end to GitHub. They aren't writing commits with the intention of showing their work, they are using commits to save their work before signing off, or to trigger CI. They aren't proficient enough with Git to go back over these and clean them up, as would be expected in a project like the Linux kernel.

If that's the state of developer proficiency with version control then, ideal workflows aside, we need a way to prevent those noise commits from ending up in master, and the easiest way is to squash with every pull request, as part of the "merge" automation.
The first sentence seems fine (humans are somewhat obviously just on the cusp of general intelligence, in evolutionary terms).

The second sentence starts with a "perhaps", so isn't trying to present itself as fact, though agree is still overstated. My best guess is it's about right (I think 5% is somewhat of an underestimate, but not like massively so).

Seems like a reasonable criticism to me of the post. Standards for posts on LessWrong are mostly just like normal blog posts, though people try pretty hard to be precise in their guesses (hence the use of 5% in the above, which I think by people not used to LessWrong communication norms reads as making a reference to an established fact or scientific study or something).
The US isn’t fighting in Ukraine so that’d be a strange result. Especially since our surplus weapons with novice operators have laid waste to the invasion force of what was considered to be the 2nd or 3rd strongest army on the planet..
Integrity is good, but there's no universal law dictating that it will always prevail no matter what.

That said - I guess - it's not surprising that most of HN (and hope that most non-ignorant people) would agree that a lot of states are way over the optimum non-integrity point.

(For example intelligence and counter-intelligence toward geopolitically important adversarial targets is probably something that makes sense, drone-bombing random groups of people because war-on-something hysteria probably doesn't.)
I've been using Blot for years (for two websites), and I can't say enough good things about it. Happy to see it featured here!
In both cases we're just "hoping" that the result is what we want. Merging is acknowledging the parallel development and explicitly dealing with it; rebasing is pretending it never happened and applying my patches on top of a codebase that I have never seen before. In my experience, rebasing is much more likely to fail in weird and dangerous ways. But I'll admit Git's merging leaves a lot to be desired too -- that's part of what I'm complaining about, and what attracts people to rebase.
Omar Mir Seddique Mateen was not a "Christian Dominionist" and I'm pretty sure you knew that already.

"These same people"—which in this thread means Brendan Eich—did not say "thank God for AIDS." And I'm pretty sure you knew that already too.

Please stop.
I agree. Mercurial at Meta was THE BEST version control experience I ever had. In 2023, git is worse than mercurial. Stack sets are superior.
The medium is the message here, the macbook is just bait.

The pure LLM is not effective on tabular data (so many transcripts of ChatGPT apologizing it got a calculation wrong.). To be working as well as it seems to work they must be loading results into something like a pandas data frame and having the agent write and run programs on that data frame, tap into stats and charting libraries, etc.

I’d trust it more if they showed more of the steps.
If you're doing proper atomic commits, as most people critiquing squashing probably are, the overhead of making separate PRs for each would be ludicrous. It depends heavily on the situation, but in favorable conditions (greenfield development of some simple CRUD app, for instance) you can easily produce dozens of clean, atomic commits a day. As part of the same PR, those take almost no time at all to review. Put into separate PRs, you'd be wasting a lot of time and effort both on the reviewer's and reviewee's side.
Qubes does allow creating a VM for just about any program or service. But, in my experience, it suffers from latency. So, while fine for web browsing, it wasn't too keen on playing videos. YMMV of course, but Adobe products are already hogs without the emu layer.
In the back of my mind I’m worried that our competitors have a faster software development cycle.
It does, if you interact at the CLI, where a "PR" concept does not exist.

git diff ^initial-commit~1 final-commit

However for that to be available after a contribution has been included in the master branch, one has to use merge commits.

Otherwise there are no inherent markers as the graph has been flattened in to a linear sequence. One then has to make use of external tools, or commit comment conventions to recreate what was actually done or intended.
Peter Sellers playing 3 different roles. Poor guy really did get type cast in the weirdest way.
1. If, and only if, you are doing ML or multimedia, get a 128GB system and because of the cost of that RAM, it would be foolish not to go M3 Max SoC (notwithstanding the 192GB M2 Ultra SoC). Full Stop. (Note: This is also a good option for people with more money than brains.)

2. If you are doing traditional heavyweight software development, or are concerned with perception in an interview, promotional context or just impressing others at a coffee shop, get a 32GB 16” MBP system with as large a built-in SSD as you can afford (it gets cheaper per GB as you buy more) and go for an M2 Pro SoC, which is faster in many respects than an M3 Pro due to core count and memory bandwidth. Full Stop. (You could instead go 64GB on an M1 Max if you keep several VMs open, which isn’t really a thing anymore (use VPS), or if you are keeping a 7-15B parameter LLM open (locally) for some reason, but again, if you are doing much with local LLMs, as opposed to being always connectable to the 1.3T+ parameter hosted ChatGPT, then you should have stopped at #1.)

3. If you are nursing mature apps along, maybe even adding ML, adjusting UX, creating forks to test new features, etc.. then your concern is with INCREMENTAL COMPILATION and the much bigger systems like M3 Max will be slower (bc they need time to ramp up multiple cores and that’s not happening with bursty incremental builds), so might as well go for a 16GB M1 MBA (add stickers or whatever if you’re ashamed of looking like a school kid) and maybe invest the savings in a nice monitor like the 28” LG DualUp (bearing in mind you can only use a single native-speed external monitor on non-Pro/Max SoCs at a time). (In many cases, can even use an 8GB M1 MBA for incremental builds because, after loading the project, the MacOS memory compressor is really good and the SSD is really fast and you can use a real device instead of a Simulator. But do you want any M2 MBA? No, it has inferior thermals, is heavier, larger, fingerprints easy, lack’s respect and the price performance doesn’t make sense given the other options. Same goes for 13” M1/M2 Pro and all M3 Pro.)

Also, make sure you keep hourly (or better) backups on all Apple laptops WHILE CODING. There is a common failure scenario where the buck converter that drops voltage for the SSD fails, sending 13VDC into the SSD for long enough to permanently destroy the data on it.
https://youtu.be/F6d58HIe01A
I can't read the article, but the intro is interesting.

"The authors’ most striking finding is a surge in short sales—bets that a security’s price will fall—of an exchange-traded fund (etf) listed on the New York Stock Exchange under the ticker eis, which tracks an index of Israeli shares. In September an average of 1,581 shares a day of EIS were sold short, representing 17% of the daily total trading volume. On October 2nd, five days before the attacks, a whopping 227,820 shares were shorted, representing 99% of total volume. Rather than reflecting a souring of market sentiment, the increase in activity seems to have come from just two trades."
It's OK to just not like Apple. You don't have to justify your own feelings with pejoratives towards other peoples' choice of laptop.
You can "just" do anything. The problem is that things don't "just" work that smoothly. What happens when the feature or bug fix I'm working on demands a refactor or a name change or something of that sort. I could put the refactor in a separate PR, but what if I'm not sure of the changes until I get far enough along with implementing the feature or bug fix? I might want to go back and tweak the refactor I did. So if I put up a PR as soon as the refactor was done, I'll then need to put up another PR with tweaks to it and then a third PR with the actual feature or bug fix. Or I could just put them all up in one PR together broken down by commit. Reviewers can review commit-by-commit. Or I could wait until I've finished everything, and then I'm left with submitting a single PR or splitting them into multiple PRs are submitting them simultaneously. (And dealing with stacking them appropriately.)

This is of course a balancing act. Which is my point. Sometimes it makes sense to split things up into multiple PRs. But sometimes it makes sense to fatten a PR a little bit with multiple commits. You can't just say "small PRs are better." Size is but one dimension of what makes a good PR.

This is why I personally use both "squash & merge" and "rebase & merge." If a PR has a bunch of commits but is really just one logical change, then I'll squash it. But if a PR has thoughtful commits, then I'll rebase it and do a fast-forward merge.

My bottom line is that I try to treat the source history as well as I treat the source. The source history is a tool for communicating changes to other humans, both for review and for looking back on. Squash & merge has a place in that worldview, but so does rebase & merge.
The compiler does not, but tools like clang-tidy do, (bugprone-assignment-in-if-condition in clang-tidy) but that didn't exist back then.
> shifting to a squash-rebase-and-merge workflow. The benefits are clear: rebasing creates a cleaner, more understandable history & state of the world without the clutter of merge commits. Trunk branches remain linear, and branches function as brief, atomic diffs off the trunk.

Arguably, you could achieve the same result of a trunk that looks clean and linear, if the tooling just had an option to hide the feature branches, and show you only the merge commits. But you could also keep the possibility of looking inside the old branches and their individual commit messages, if you wanted to.
expect new, certified companies with security and finance, to become the officially required caretakers along with many fees; expect new monetized systems to distribute security patches passed through new bureaucracies, with logging of the government ID of all recipients; expect the restriction of new security patches to authorized users only.
Extremely useful almost every time. Why wouldn’t we re-write our personal history just before merging into the main permanent history?
The Secret City was a huge inspiration for my childhood sketching.
Pioneers yet I still can't buy a Toyota EV.
Squash before rebase?
That’s not even correct on a technicality, because you switch mid-sentence from discussing “war” to discussing “declaration of war.” A declaration of war is plainly different from a war. Declarations of war are frequently made well after a war has begun or well before any fighting takes place. And as you state, many wars are fought without any declaration of war.