Ripgrep has saved me so, so much time over the years. It's become an invaluable tool, something I install the moment I start up a new system. It's essential for navigating older codebases.
My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now.
> My only complaint is there are a couple of characters that the -F (treat as literal) option seems to still treat as a special character needing some kind of escape - though I don't remember which ones now.
If you have an example, I can try to explain for that specific case. But `-F/--fixed-strings` will 100% turn off any regex features in the pattern and instead will be treated as a simple literal. Where you might still need escaping is if your shell requires it.
How about -F -regexthatlookslikeaflag? Verbatim, that errors out as the command line parsing tries to interpret it as a flag. If you don’t have -F, then you can escape the leading hyphen with a backslash in a single quoted string: '\-regex…', but then you don’t get fixed string search. And -F '\-regex…' is a fixed string search for “backslash hyphen r e g e x”. The only way is to manually escape the regex and not use -F.
The convention is use use -- to denote the end of options in command-line tools - anything after that is parsed as a normal argument even if it starts with a dash. If rg doesn't support that it should.
ripgrep has saved me so much time, I also use it now with LLMs and remind them they have ripgrep available! I added a donation on github, thanks for all your work.
Short opinionated summary is: nicer API, fewer footguns, more features, better support for calendar durations, integrated tzdb support and lots more to be honest.
Note that `std::time` just gives you a platform independent but bare bones access to monotonic and system clocks. Some kind of datetime library is needed if you want to do anything with Unix timestamps beyond treat them as an integer.
When I tried, the only options from Amazon were 'transfer to my device' and that only works if you have a Kindle. There was 0 way to just download the stupid file and let me copy it myself.
When I said "bypass", I meant I ditched my kindle for a kobo and stopped buying books on amazon entirely.
There is a library built into the kobo you can purchase from, which I do for newer books. However, I've been on a classics kick and I pirate them tbh. Dumas doesn't mind.
I hadn't given the online library much of any thought. I kind of assumed it would not have access to anything I wanted. I decided to take a look, and lo-and-behold, it has pretty much everything I've wanted to read recently. The prices are pretty good, it's like $9 for some and a few on sale for $2 which is a steal.
I hate Amazon's decision to do this. It doesn't even make business sense. You can't tell me they're making that much profit off of Kindles that it makes sense. The book sales have got to be worth more than that in the long run.
A lot of authors only ever offer on Amazon now, which leaves those of us without Kindles (I love my Kobo) in a difficult spot.
Frankly I would write it as anti-competitive. How are other e-reader companies supposed to survive when Amazon owns all the e-books and can just decide that only their e-readers are allowed? No one else has even a fraction of the market.
The fact that they did this, kind of proves that it does make business sense? This is Amazon. I don’t buy that some random person ordered this to be implemented without any data or motive.
I like HN generally, but there are a handful of things I wish it had:
* The ability to save comments, as well as posts
* Ideally a separate 'favorites' and 'read later' category
* Some kind of [tags] on posts, ideally something
individuals can contribute to. It would be easy to add from an existing set of tags, adding a unique new tag would be harder and require maybe an older account or more 'points' or whatever.
* Maybe some kind of 'bump' system when linking to things that have already been posted? It feels a bit silly for there to be like 10 duplicates of a post from different time periods. But maybe that's better than the alternative, not sure.
> * Maybe some kind of 'bump' system when linking to things that have already been posted? It feels a bit silly for there to be like 10 duplicates of a post from different time periods. But maybe that's better than the alternative, not sure.
I kind of enjoy it. Some posts have become like a yearly/bi-yearly occurrence, and if I enjoyed the discussions the previous times, I'll most likely enjoy the discussions this time too.
As long as it's not the same stuff every day, I'm fine with things being re-posted once a year or so, long enough for me to forget I read the previous one.
And it actually does avoid duplicates in the short term, as long as the submitted url is identical. I'm not sure what the time threshold is exactly, but I know if you resubmit something that has been submitted in the past few days, it will count it as a vote on the original instead.
I appreciate it, as it helps me to not 'favorite' many comments, but only those that actually strike me as worth saving when they are so detailed as to be a post of their own!
In a lot of ways, HN's intentionally aescetic design works against itself. People can be here for years and not notice features because the grey on grey layout encourages feature-blindness.
It helps when you view it like a graph of people making commitments of their opinion. You can checkout a commit by clicking on the time and then run the commands by clicking on their label. There are also the plumbing commands like 'latest', that you only find, if you know them.
Most of the time I'd choose to hide posts tagged AI. (No disrespect to people posting/discussing AI, it's just not a topic that I have much intellectual curiosity for.)
Unfortunately sometimes I'd choose to sort by "drama", and get my rant on about the latest Ruby shitfight, or whatever Matt/Automattic or Elon/Grok/X are doing. And me giving in to that temptation would probably make the site objectivity worse, so perhaps it's better the way it is?
When I was looking, the older models were around $500. Looks like they came down in price. I also looked at used, but my company stipend/discount would only apply to new.
I don’t think I can take that claim by itself as necessarily implying the cause is hardware. Consumer OSes were on the verge of getting protected memory at that time, as an example of where things were, so if I imagine “take an old application and try to run it” then I am immediately imagining software problems, and software bit rot is a well-known thing. If the claim is “try to run Windows 95 on bare metal”, then…well actually I installed win98 on a new PC about 10 years ago and it worked. When I try to imagine hardware changes since then that a kernel would have to worry about, I’m mostly coming up with PCI Express and some brave OEMs finally removing BIOS compatibility and leaving only UEFI. I’m not counting lack of drivers for modern hardware as “hardware still changes” because that feels like a natural consequence of having multiple vendors in the market, but maybe I could be convinced that is a fundamental change in and of itself…however even then, that state of things was extremely normalized by the 2000s.
Drivers make up a tiny portion of the software on our computer by any measure (memory or compute time) and they're far longer lasting than your average GUI app.
On the other hand, the main reason why Y2K happened was because a lot of major orgs would rather emulate software from the 60s forever than rewrite it. I'm talking like ancient IBM mainframe stuff, running on potentially multiple layers of emulation and virtualization.
We rewrite stuff for lots of reasons, but virtualization makes it easy enough to take our platforms with us even as hardware changes.
Pretty sure if I downloaded and compiled Tcl/Tk 7.6.x source code on a modern Linux box, it would run my Tcl/Tk 7.6.x "system monitor" code from 1995 or 1996 just fine.
Do you have any examples that aren't because of the OS (as in, not trying to run a 90's game on Windows 11) or specialized hardware (like an old Voodoo GPU or something)?
The program may work fine on its original OS, and the OS may work fine on its original hardware, but for someone trying to actually run their business or what have you on the software these facts are often not particularly helpful.
Backwards-compatibility in OSes is the exception, not the rule. IBM does pretty well here. Microsoft does okay. Linux is either fine or a disaster depending on who you ask. MacOS, iOS, and Android laugh at the idea. And even the OSes most dedicated to compatibility devote a ton of effort to ensuring it on new hardware.
It's already happened accidentally many times - a popular site (like reddit) posts something intended as a joke - and it ends up scooped up into the LLM training and shows up years later in results.
It's very annoying. It's part of the problem with LLMs in general, there's no quality control. Their input is the internet, and the internet is full of garbage. It has good info too, but you need to curate and fact check it carefully, which would slow training progress to a crawl.
Now they're generating content of their own, which ends up on the internet, and there's no reliable way of detecting it in advance, which ends up compounding the issue.
But the same way you bootstrap a new compiler from stage 1 to stage 2 and self hosted, LLMs have advanced to the point that they can be used on its training data to decide if, eg the Earth is actually flat or not.
Most facts about the world can't be deduced from logic. They're just facts, to memorize. The King's lefthanded. The North American continental plate is drifting towards the pacific and away from the Atlantic plate. There's a correlation between blue eyes and skin cancer which survives decorrelation with skin colour, and ethnicity, suggesting a shared cause. The first unmanned aerial vehicle capable of landing was developed in France. A general named Rogers led the British in the war of 1812.
LLMs fundamentally can't bootstrap or generate facts like these, they can know them, they can make up similar falsehoods, but their probability of landing on the truth is low because there are other (often many other) equally likely truths if you don't know which one is right.
(Please note: I made up all the "facts" in this post)
I was rather explicit about that, you memorize them from trusted sources (or directly observe them). There's no question. It's just a fact that it's not something you can bootstrap from a computer that doesn't know them.
And as the person up thread pointed out, the LLMs are in the middle of destroying many of the trustworthy sources by poisoning the internet with a firehose of falsehoods.
Are you saying human brain is kind of similarly vulnerable to well-crafted facts? Does it mean any intelligence (human or non-human) needs a large amount of generally factual data to discern facts from fakes, which is an argument toward AIs that can accumulate huge swath of factual data?
I feel like you're trying to twist my words into something they don't resemble at all.
I'm not saying anything is vulnerable to anything. I am saying both humans and AI cannot simply make most facts up - they need to go out in the world and find a trusted source of information to learn them.
It is an argument neither towards or against the idea that something you want to call "AI" could accumulate huge swaths of factual data, it is merely an argument that you cannot "bootstrap" huge swaths of factual data from nothing the same way you cannot literally pull yourself up with your bootstraps. If you want the information, you have to collect it from the environment.
The difference that a compiler is (generally) deterministic. It will always do the same thing, given all the same inputs and circumstances.
An LLM is not, it's probabilistic text. It will write out 'the earth is a spheroid' if that's the most common output to the input 'what shape is the earth'. But it does not understand what it is writing. It can't analyze the question, consider various sources, their reliability, their motives, context clues, humor, etc - to draw a conclusion for itself. It can't make a mistake and then learn from that mistake when corrected.
probabilistically, why does that matter? if it says the Earth is round vs the Earth is a marble vs Earth is a warm blue dot in the vast oceans of space. Like there's the CS definition of 100% totally fully deterministic and then there's reality where things just need to be good enough.
What if 0.5% of the time it says that the Earth is flat? Being used millions of times per day, it will tell thousands of people that the earth is actually flat, and may convince some of them of this false fact.
That's a pretty good one but I think a better question to challenge me is what if 1% of the time, Claude code does rm -rf ~, which has been going around. Some people are just gonna jump. Some will make it, some won't. I have backups.
Whatever shows up most commonly in the training data is is what an LLM will output. It's more complicated than that of course, but that's the basic idea.
And I think you missed the point. If you knew which were 'correct' and which were 'incorrect' then you could avoid the problem altogether. But that would mean someone would have to curate the entire internet, looking for anything that's 'incorrect' (or intended as humor) and making sure it doesn't end up in the training data Or LLM-generated content, to avoid cascading failures.
That's an unbelievable amount of work. It's essentially impossible, no matter how much money you throw at it. There's so much content being made every day you couldn't even keep up with what's being added let alone what's already there.
> Whatever shows up most commonly in the training data is is what an LLM will output. It's more complicated than that of course, but that's the basic idea.
The most common thing in the training data is the letter 'e'. If you're going to explain how an LLM works it needs to explain why it's able to form sentences at all.
In particular answering questions is a behavior which only appears after posttraining, and the posttraining objective has absolutely nothing to do with what's "most common" in the pretraining data.
> But that would mean someone would have to curate the entire internet, looking for anything that's 'incorrect' (or intended as humor) and making sure it doesn't end up in the training data
Show the LLM the source URL during pretraining so it can cluster them together.
The cheap version of this technique is to find trustworthy text (Wikipedia, answers you paid people to write, high upvoted Reddit comments) and train on it more than once. The rest falls out through emergent magic (reliable sources have different writing styles than unreliable ones and RL points it to the part of latent space with the reliable sources, or something.)
Besides that, if it encounters 95%/5% right/wrong answers to some question during training, that will have a different effect than 100%/0%. It does know when something is debated.
Those goodbyes feel so corporate. After being laid off, the last thing I would want is to hear more corporate speak. It's the sort of thing a manager would send to an employee, not something employees at similar levels would send one another.
reply