With many other languages, you have a lot of functionality out of the box. Certainly, there have been bugs and security issues, but they're a drop in the bucket compared to what you see in the JS ecosystem. With other languages, you have a much smaller external dependency graph and the core functionality is coming from a trusted 3rd party.

I think they’ve been caught in a bad spot. They’re a profitable company, but nowhere on the scale of Microsoft. And they don’t have billions of VC to effectively price dump. Other tools that can focus on one thing and burn cash are advancing quickly and some of them don’t really need an IDE at all.

The semi-recent introduction of ACP integration in the JetBrains IDEs has been a nice bridge. But now it’s confusing how everything comes together. I really hope they can survive.

I do wish we had DRM-free purchases like we have with MP3s. But this is a big step up over streaming services. The Movies Anywhere integration is handy as well.

Is there a better way to do seller verification? It does seem like an information leak to me. Craigslist and eBay don’t share my identification as a potential buyer. I don’t love the marketplace being tied to a social network, but it’s what many people are using these days.

If you're interested in the project, please give it a try. Or, if you just want to chat Ruby compilers, feel free to drop into one of our community channels (Slack or GitHub Discussions).

https://github.com/truffleruby/truffleruby.

For those cases where you're writing a native extension to primary bridge over to a native library, you may find either FFI or Fiddle handle your use case quite well.

¹ -- https://youtu.be/-iVh_8_J-Uo?si=8uVFLiF3NtjWgfR1

¹ -- https://github.com/graalvm/graalvm-ce-builds

² -- https://github.com/graalvm/mandrel

RLHF = Reinforcement Learning from Human Feedback

https://en.wikipedia.org/wiki/Reinforcement_learning_from_hu...

The only real downside with the TV is that uses more power than I’d like and, consequently, throws off more heat than I’d like. Otherwise, it’s been very reliable and looks fantastic. I’m curious what I’m missing.

Comments URL: https://news.ycombinator.com/item?id=46607891

Points: 6

# Comments: 0

It’d be very handy if we had a performant remote desktop option for Linux. I could resume desktop sessions on my workstation from my laptop and I could pair program with remote colleagues more effectively.

In the past I’d boot into Windows and then boot my Linux system as a raw disk VM just so I could use Windows’s Remote Desktop. Combined with VMware Workstation’s support for multiple monitors, I had a surprisingly smooth remote session. But, it was a lot of ceremony.

https://news.ycombinator.com/newsguidelines.html

Repeatedly, you've been dismissive and insulting. It's not conducive to productive conversation. Your characterization of what I do or how I work is wrong. You latched on to some small part you thought would let you "win" and ran with it. If you actually care, I do a lot of open source work so you can find exactly how I work. Naturally, you can't see what I do in private, but I assure you it's not significantly different.

I aim to ship reasonably complete functionality. The "V" in "MVP" means it needs to be viable, not just minimal. Shipping some part that doesn't work standalone isn't useful to anyone. Yes, the PR is smaller, but now the context for that work is split over multiple PRs, which may not be reviewed by the same people. No one really has the full picture beyond me, which I guess is a good way to get my PRs rapidly approved, but a terrible way to get feedback on the overall design.

I don't work with you so I don't particularly care how you work. Again, I was offering up other solutions than running "git commit" every 15 minutes. If you want to manually simulate filesystem snapshots, that's your prerogative. But, you're incorrect that any model other than the one you employ is niche an not how software is written. Elsewhere you dismissed the examples of large, open source projects as being unique. But, you'll find substantially smaller ones also employ a model closer to what I've described.

I don’t have any data to support this, but I suspect a sizable segment of PC gamers aren’t going to view this as the impetus they needed to splurge on the OLED. I doubt very many of those people see this as a double-edged sword. It doesn’t particularly matter to them what Valve’s confidence in the product is if they can’t afford to buy one. While some may buy the step-up model, many won’t. Valve loses out on the sale of the hardware and on the sale of the software to run on it. And I’d be concerned that ceding the lower end of the market is going to poison the well like video game consoles in the early 80s.

With that said, Valve almost certainly has the data and would know better than me. It seems like a gamble to me. Maybe the post is correct and this is all about price anchoring for the new Steam Machine and Frame.

But, if you're really worried about losing 15 minutes of work, I think we have better tools at our disposal, including those that will clean up after themselves over time. Now that I've been using ZFS with automatic snapshots, I feel hamstrung working on any Linux system just using ext4 without LVM. I'm aware this isn't a common setup, but I wish it were. It's amazing how liberating it is to edit code, update a config file, install a new package, etc. are when you know you can roll back the entire system with one simple command (or, restore a single file if you need that granularity). And it works for files you haven't yet added to the git repo.

I guess my point is: I think we have better tools than git for automatic backups and I believe there's a lot of opportunity in developer tooling to help guard against common failure scenarios.

It's not really hand curation if you're deliberate about it from the get-go. It's certainly not eating up 80% of anyone's time.

Structuring code and writing useful commits a skill to develop, just like writing meaningful tests. As a first step, use `git add -p` instead of `git add .` or `git commit -a`. As an analog, many junior devs will just test everything, even stuff that doesn't make a lot of sense, and then jumble them all together. It takes practice to learn how to better structure that stuff and it isn't done by writing a ton of tests and then curating them after the fact.

> I think you must be kind of senior and you can get away with just insisting that other people be less efficient and work in a weird way so you can feel more comfortable?

Your personal productivity should only be one consideration. The long-term health of the project (i.e., maintenance) and the impact on other people's efficiency also must be considered. And efficiency isn't limited to how quickly features ship. Someone who ships fast but makes it much harder to debug issues isn't a top performer. At least, in my experience. I'd imagine it's team, company, and segment-dependent. For OSS projects with many part-time contributors, that history becomes really important because you may not have the future ability to ask someone why they did something a particular way.

Presumably, a branch is a logical segment of work. Otherwise, just push directly master/trunk/HEAD. It's what people did for a long time with CVS and arguably worked to some extent. Using merge commits is pretty common and, as such, that branch will get merged into the trunk. Being able to understand that branch in isolation is something I've found helpful in understanding the software as a whole.

> Caring about the history of a branch is weird, I think your approach is just not compatible with how people work.

I get you disagree with me, but you could be less dismissive about it. Work however you want -- I'm certainly not stopping you. I just don't your productivity to come at the expense of mine. And, I offered up other potential (and IMHO, superior) solutions from both developer and system tools.

I suppose what type of project you're working on matters. The "treat git like a versioned zip file" using squashed merges works reasonably well for SaaS applications because you rarely need to roll anything back. However, I've found a logically structured history has been indispensable when working on long-lived projects, particularly in open source. It's how I'm able to dig into a 25 year old OSS tool and be reasonably productive with.

To the point I think you're making: sure, I care what changed, and I can do that with `diff`. But, more often if I'm looking at SCM history I'm trying to learn why a change was made. Some of that can be inferred by seeing what other changes were made at the same time. That context can be explicitly provided with commit messages that explain why a change was made.

Calling it incompatible with how people work is a pretty bold claim, given the practice of squash merging loads of mini commits is a pretty recent development. Maybe that's how your team works and if it works for you, great. But, having logically separate commits isn't some niche development practice. Optimizing for writes could be useful for a startup. A lot of real world software requires being easy to maintain and a good SCM history shines there.

All of that is rather orthogonal to the point I was trying to add to the discussion. We have better tools at our disposal than running `git commit` every 15 minutes.

For my part, I find the “local history” feature of the JetBrains IDEs gives me automatic checkpoints I can roll back to without needing to involve git. On my Linux machines I layer in ZFS snapshots (Time Machine probably works just as well for Macs). This gives me the confidence to work throughout the day without needing to compulsively commit. These have the added advantage of tracking files I haven’t yet added to the git repo.