prasoon2211

I used to be on 5.4 high for most of my work. I have switched completely to 5.5 medium now. I would highly recommend trying it out

- 5.5 is significantly more token efficient than 5.4 - the same task takes often a third of the tokens

- because of this, is it also much faster to do the task

- you get high "intelligence" per token even after accounting for token efficiency - 5.5 medium is just under 5.4 pro levels of intelligence (imo). It has found tricky bugs for me that all other models failed at

So overall, ideally you will end up with more intelligent, faster model for slightly cheaper.

May I ask if you're an insider / some who has first hand information about this?

I founded a UG and a GmbH in 2024. It took me 3 months total including visits to the notary (who charges a non-insignificant sum for their services).

I did this as a subsidiary for a US company and literally had to email and call people every few days to move the process along (mostly, it was the banks who somehow expected us to be a multi-national company and wanted to charge an arm and a leg just to let us open a bank account. Most banks outright refused us).

When the notary finally filed the paperwork to the court, the court replied after a few weeks with additional clarifications for which we had to go AGAIN to the notary to do the whole song and dance of them chanting at us in German at 1000 words per minute.

Everything took painfully long and delayed investment for while. People have absolutely no idea how painful it is to merely have the incorporated entity available. Then, it takes a few weeks to get your tax ID - this is when you can start employing people / accepting payments etc.

This is incorrect. Taxes, pensions and labour laws apply according to the country where the EU Inc is operating.

iirc he (or his colleague) did mention somewhere on X that most of the PRs are small

Agree on all points, especially half of my friend circle being unemployed at one point.

Folks with amazing jobs having to spend >1y trying to find a "meh" job. Pretty much impossible to find a job without fluent German.

Most people actually using python do not start off in scripts. Usually, I would mess around in IPython / Jupyter for a couple days until I have something I'm happy with. Then I'll "productionize" the project.

tbh this has been a sticking point for me too with uv (though I use it for everything now). I just want to start of a repl with a bunch of stuff installed so I can try out a bunch of stuff. My solution now it to have a ~/tmp dir where I can mess around with all kinds of stuff (not just python) and there I have a uv virtualenv installed with all kinds of packages pre-installed.

This is partially why, at least for LLM-assisted coding workloads, orgs are going with the $200 / mo Claude Code plans and similar.

Presumably the tab based edit-prediction model + $5 of tokens is worth the (new) $10 / mo price.

Though from everything I've read online, Zed's edit prediction model is far, _far_ behind that of Cursor.

RLHF is not the "RL" the parent is posting about. RLHF is specifically human driven reward (subjective, doesn't scale, doesn't improve the model "intelligence", just tweaks behavior) - which is why the labs have started calling it post-training, not RLHF, anymore.

True RL is where you set up an environment where an agent can "discover" solutions to problems by iterating against some kind of verifiable reward AND the entire space of outcomes is theoretically largely explorable by the agent. Maths and Coding are have proven amenable to this type of RL so far.

Right, it took me a couple of re-reads and I (non-native speaker) ended up asking ChatGPT about it and yes, the sentence is worded incorrectly

As others have said, this is classic selection-effect. Lina Khan isn't coming out and telling people about

- the companies that died because acquiring them was too much of a hassle

- the companies that died or never got funded / started because the investors couldn't see and exit path

- the companies that got acquired piecemeal (Windsurf, Inflection), leaving the early employees with NOTHING simply to avoid the ire of anti-trust hawks at the FTC. This has irreversibly damaged the SV bargain - early startup employees work hard in case of an acquisition, they get rich.

So Lina Khan can keep patting her own back but there's a reason founders, early-stage startup employees and investors disagree.

I worked at a company where we copied this from Amazon for a specific type of meeting (bi-weekly review). But we also had the other "normal" type of meeting.

People never read the documents before the meeting in those "normal" meetings.

The challenge with your suggestion is that people will half-ass the doc reading before the meeting - we tried doing this for the "normal" meetings. It was obvious the people skimmed the doc before the meeting. You're also now relying on the manager (if there even IS one for everyone in the meeting!) to care about this.

So, in practice, giving people dedicated 10 minutes at the start of the meeting works far better.

Besides, in most "normal" meetings, the main presenter often ends up discussing background / context for 10 minutes interspersed throughout the meeting anyway. In the "pre-read" meetings, you're just compress that to the first 10 minutes while increasing the amount of information transferred.

This is really cool! Just started using it today. It's missing some of superwhisper's ease of use but other than that, 10/10

I tried using it for something non-trivial. And:

> 429: Too many requests

Mind you, this is with a paid API key

Exactly this. In Germany, the median software developer is treated (and paid) pretty much the same as a blue collar worker, both by their company and by society at large.

From calling it "IT" to paying peanuts, no wonder no one smart and ambitious wants to get into CS here. All the smart kids seems to want to go into consulting and finance. So, of course Germany doesn't see the kind of outsized success in the Tech industry like the US or even the UK.

Volkswagen's (and in general other automaker's) software sucking is simply a fact downstream of that.

This makes sense. And this is only accelerating - I talk to businesses in Germany and there's a genuine, non-insignificant number of people who want their data to be /physically/ in Europe.

Take this to its logical conclusion and basically, every company will need to segregate their data in regions. Most cloud platforms aren't really designed this way but it's coming.

There was a data locality law that India passed and Stripe had to do this massive migration project to segregate this data. I shudder to imagine what a more complex system would look like under such data locality laws.

This is tangential but you seems really knowledgeable about the payments industry. Can you perhaps recommend some sources to understand how the payments infrastructure works (POS but also web/online/mobile)? I only seem to have a broad idea and would love to understand the nitty-gritty of it all!

I am utterly baffled by people who use the phrase "The Unix Philosophy" for justifying a piece of software but don't understand that Unix philosophy is in the context of software that can be composed together. That is why the other tenet of the Unix philosophy is to use text streams for all I/O.

Yeah, I actually looked at atom sometime back. They have a problem with long lines because their regex engine runs in O(n^2). I suggested that they switch to a regex engine that runs in O(n). https://github.com/atom/atom/issues/979#issuecomment-7770371...

I don't know what happened after that. Maybe they will act on this. The only problem with the O(n) engine was that a lot of TextMate grammars for languages wouldn't work with atom but that was easily resolvable by writing them anew.

> The number from a few years ago showed college freshmen using Macs by 70%.

In the US, perhaps. Where I study, I can count the number of people owning MacBooks on my fingers. They're still way too overpriced/lacking in hardware compared to PCs at the same market rates.

Yes, you really should. That was my intention with this post all along.

Can someone please explain how this is different from CodeMirror vim mode? I am an emacs user and know only the basic vim commands and so, I cannot tell if there is something fundamentally different between the two implementations.

The first time I learnt of fork (from an OS book), the example had three branches to the if statement after fork - and the first tested for a negative pid. I suspect that the reason this link has 400 odd upvotes is because more people aren't learning OS the correct way in the beginning. Or maybe my OS book was nice. IDK.

I see people conveying their tales of the hot weather - where the temperatures rose to 95 to 100 degree fahrenheit - just around 35 to 40 degree celsius - for a brief few days each summer.

The truth is, this is a little more than moderately hot for many parts of the world. Here in India (in the parts around the capital), you're lucky if temperature keeps on the lesser side of the 45 degree mark. And this happens for weeks on end, not just for a few days. Just before the arrival of monsoon, it is both extremely hot and extremely humid - humid as in drenched humid.

Now imagine this - you've got a 45 degree blazing heat on top of the 98% relative humidity. The fans just don't seem to work and you're sweating profusely from the minimal of exertions. Add to this not having an AC and you get an idea how most of us lived for the past decade or so. It got so hot that you felt a physical pressure pushing you down and all we could do was lie down on the cold floor as we waited for night to bring some relief with it.

Things are changing though and most people are getting ACs now. The floor is no longer cool.

Ah, but you forget to provide a reason to support your claim unlike me, who presented a basic use case which in fact refutes your claim (in the last comment).

> Emacs is obviously and inarguably not immediately intuitive.

"obviously" : I find it anything but obvious. "inarguably": Really? So it can't even be argued? Well, I don't know what to say to that.

> If it is a deal breaker for you go away from the deal.

If it wasn't already abundantly clear from my previous comment, that is exactly what I'm doing.

> And if you do not want to invest a couple of hours learning a new tool I doubt you will invest dozens of hours fixing it anyway.

First, my comment was in response to the person claiming that "those not using Atom because it's not FOSS" are having an attitude that they're entitled to the editor being open-source. I was merely trying to point out the reasons why some of us expected a text editor (not any other software but specifically a text editor) to be open-source.

Second. Since you've entirely glossed over what I was trying to say, I'll explain it again (I should use easier English, I suppose).

It is evident to me that you are absolutely oblivious to the philosophy that drives FOSS. For a software to be open-source isn't important for me because I can make changes to it - it's because anyone can make changes to it. Let me put it in easier terms: If there are a large number of people using a software, and, that software happens to be open-source, it will generally lead to the betterment of the software as time goes on. Why? Well, it's because it is not at all imperative for me to change the code - in fact I know I'll pretty much never need to patch, say, Emacs - for the software to become better because I know that there are other people who are doing so - thereby leading to a better piece of code. Examples of this kind of behaviour is spread all over the place. The Linux kernel is a pretty good example. So is git. Now, because an editor is the primary tool of a programmer, you can be sure that a very large number of people are going to use it. If even a fraction of those people contribute to the editor's source, you can be pretty certain that the editor is evolving according to the needs of the community (and not according to the organisation owning the software) since that fraction of the people contributing code will represent pretty evenly the general demands of the community. So, the editor will become better over time, evolve in a way that is representative of the demands of the community and won't die out.

Now, I'm not saying that Atom isn't a good product. Indeed, from the looks of it, it appears to be a very well rounded text editor. But again, it's not open-source and hence, the benefits that I talked of in the last paragraph won't apply to Atom. This means that the project might die out in 4-5 years. Then, there's the fact that Emacs can do much much more than Atom right now and I expect Emacs will be around 20 years from now [1]. These facts lead me to the obvious conclusion that there is no incentive for me to switch to Atom. Had Atom been open-source, then, it being a pretty great editor already, I know that it would have been much more likely that Atom would still be around 10 years from now (Why? See the last paragraph!). Then, I might have made Atom a second (actually third, second is Vim) editor that I'm proficient in. But alas! That is not to be.

Anyway, I truly hope that you understand why it is that I (and many others like me) want the text editor to be open-sourced. It's not because I will make it better - it's because I know that there are others, far more competent than me, who will, and, do so according to the wishes of the community using the software.

[1] Extrapolating from the fact that it has been around for 20 years already.

No. This is not the entitled attitude and people definitely do not think that GH absolutely must open source all their products.

The problem begins when you close-source a text editor. For me, this is a deal-breaker. I would not want to invest time and effort in learning a new tool - my primary tool, in fact - that won't stay for more than 5 odd years.

Just take sublime as an example. I've seen so many ST users, right here on HN, drooling over Atom, ready to jump ship. On the other hand, I do not see any Emacs or Vim users saying the same. This is because Emacs and Vim are very powerful editors[1] and there's no point jumping ship to another new and shiny editor that might no longer be there after a few years. Also, I've seen a lot of friction around forums regarding the fact that the author pretty much left ST2 entirely (bug fixes/enhancements) in favour of ST3. Also, the features of a closed source editor might not be well aligned with what the community wants.[2]

[1] I'm not saying that ST isn't powerful - it's okay. But, Vim and Emacs are far more powerful - because you can hack at the source itself and because generally a much larger number of people can contribute to the project (given that not many people are competent enough to actually do that or do not have the time) - [2] and, if you feel the editor/project isn't going in the right direction, you can just create your own fork and if it's good, people will actually migrate to your fork for better usage. And that really is the power of FOSS.

I'm willing to bet anything that just like Sublime was FOSS cloned to Lime (https://github.com/limetext/lime), this as well will be cloned as FOSS, if it is any good, that is.

Subatom seems like a great project title :)

> There is no reason why "editing plain text" should be anything other than immediately intuitive.

Are you suggesting that it isn't in Emacs?

Well, I remember using Emacs for the first time. It opened up and I started editing the opened file. I saved the file from the file menu (which also showed me the shortcut for saving the file the next time I have to save something). Done. Now, this is exactly what a novice would do with notepad.

I found that many people 'demonize' Emacs just because they found it unfamiliar. Sure it's unfamiliar. For about a day. Then, it's just as familiar as any other user interface. I now used Emacs for, well, the shell, the dired and wdired, multiple cursors, keyboard macros, project-wide grepping and everything in between. Getting familiar with the editor was a great thing to have done, however unfamiliar it was in the beginning.

With the benefit of hindsight, I can truly say that learning how to properly use a text editor, especially one so powerful as Emacs, is the one thing the any programmer absolutely must do. So, even if the editor isn't "anything other than immediately intuitive", it's still a good idea to wrap your head around the non-intuitive things.