nirvdrum

I'd imagine you don't want to look like you're self-promoting, but I'd really love to read more about the JPEG project. I think it could be quite good for the community. As a whole, I believe Rubyists need to stop reaching for native extensions so quickly. Whether on YJIT, ZJIT, JRuby, or TruffleRuby, all of them will benefit from having more code in Ruby. Incidentally, Chris's final conference talk¹ made the case for moving to a Ruby-based implementation for the Ruby core library.

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

Just in case you were unaware, there is and was a 100% open source variant of the GraalVM referred to as the "Community Edition (CE)"¹. RedHat built their own distribution based on that source tree called Mandrel². The closed source version is faster in many cases, but the CE release in very capable.

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

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

For anyone else unfamiliar with the term:

RLHF = Reinforcement Learning from Human Feedback

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

What makes plasma the obvious worse choice? I have a 50” plasma that still looks better than just about any non-OLED TV I’ve seen. I understand price was a concern, but OLED TVs sit in that price category now.

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.

My experience with small police departments in the US is that they either don’t have the time or the inclination to deal with small property claims. If you’re a business they’ll be there in 10 minutes, but individuals aren’t afforded the same courtesy. Eventually, citizens realize it’s just not worth the cost or the hassle to report a crime unless it helps with an insurance claim.

It doesn’t have to be like X11. Presumably, it’d be something you could disable if you’d like.

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.

I'd encourage you to read the HN guidelines, linked in the site footer:

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.

When the news hit that the entry model was being retired I thought it might not be so bad because there’s probably a deluge of used models available, either because the owner doesn’t really use it or because they upgraded to the OLED. I was astounded by how many blatant scam postings there are on Facebook Marketplace. I can’t imagine that Meta can’t detect these since every post title ends in some random four character alphanumeric string. I’m concerned now that we’re going to see an uptick in people being scammed because they want a Steam Deck but can’t afford the OLED models.

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.

I clean up commits locally as well. But, I really only commit when I think I have something working and then collapse any lint or code formatting commits from there. Sometimes I need to check another branch and am too lazy to set up worktrees, so I may create a checkpoint commit and name it a way that reminds me to do a `git reset HEAD^` and resume working from there.

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.

> But this would require hand curation? No development proceeds that way, or if it does then I would question whether the person is spending 80% of their day curating PRs unnecessarily.

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.

> Why do you care about the history of a branch?

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.

If you’re just committing for your own sake, that workflow sounds productive. I’ve been asked to review PRs with 20+ commits with a “wip” or “.” commit message with the argument: “it’ll be squash merged, so who cares!”. I’m sure that works well for the author, but it’s not great for the reviewer. Breaking change sets up into smaller logical chunks really helps with comprehension. I’m not generally a fan of people being cavalier with my time so they can save their own.

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.

Having immutable objects by default isn’t incredibly commonplace outside of functional languages. It certainly isn’t unique to Ruby and seems out of place in a discussion comparing Ruby to Python. Fortunately, you can defensively freeze any objects you’re passing around to avoid the most common issues with mutable objects.

Immutable strings is a more popular programming language feature and Ruby has a mechanism for opting into that. It’s so commonplace that the complaint usually isn’t that a string can be modified, but rather that every source file includes a magic comment to prevent that. Besides data safety, the VM can optimize frozen strings, so popular linters will flip that setting on for you. String mutability isn’t a practical issue for modern codebases. And, as language design goes, it’s kinda nice not needing to use a parallel set of classes for mutable and immutable string data IMHO.

With that said, the magic comment is a wart and folks are looking at making immutable strings the default. But, there’s a strong desire to avoid breaking the world. The Ruby Core team is keen to keep the lessons learned from the Python 2 -> 3 migration in mind.

Plaid still rubs me the wrong way. Not selling to 3rd parties is great. But, everyone uses it, so that's still a lot of people getting data I don't necessarily want them to have. If I want to link a bank account to a credit card account in order to pay my bill, there's zero reason for that credit card company to have access to my bank transaction data. I still do the ACH deposit verification method where I can in order to avoid Plaid. I'd love more granular controls here or an audit log of what was pulled in.

SimpleFIN¹ looks compelling. Actual Budget can use that and it seems to work more like a privacy-oriented Plaid. But, now you need to trust a much smaller player. Really, I wish this were all standardized with strict privacy requirements.

¹ -- https://www.simplefin.org/

Actual Budget uses SimpleFIN [1] in the US. The integration is pretty good. The big alternative is Plaid and I don't trust them at all. It's a shame we don't have a standard for electronic banking yet.

[1] -- https://beta-bridge.simplefin.org/

If all you're looking to do is produce a design the quickest way possible, then sure Fusion often wins. Just as there was a time where buying Maya made more sense than using Blender. But, FreeCAD offers other niceties, like being able to work offline, using an open file format, performant non-web UI, generally avoiding vendor lock-in. And Autodesk already did a major rug pull with Fusion360 licensing once.

I mostly design functional 3D prints. I've found FreeCAD 1.0 fixed most of the annoyances I ran into and I'm pretty productive with it. But, I didn't come into it with an expectation of a SolidWorks or Fusion clone. I learned the tool with its own idioms and it seems pretty straightforward to me. It's not perfect by any means and I've run into the occasional bug. To that end, I've found reporting bugs with reproducible steps goes a long way to getting things fixed.

I'm not sure what it is about CAD in particular, but I find everyone wants the "Blender of the CAD world" while skipping over the decade of investment it took to get Blender where it is. For a long time, discussions about Blender were dominated by complaints about the UX. If we didn't have folks willing to work past a hit to productivity in order to make an investment into Blender, we wouldn't have the amazing open source tool we have today. FreeCAD has all the expectations of a high quality open source CAD tool with hardly any of the investment. Just getting people on /r/freecad to file issues is surprisingly challenging.

By all means, if you're happy with Fusion and don't mind the licensing, have at it. I'm sure there's functionality in there without an equivalent in FreeCAD. I'd personally rather not have my designs locked up in Fusion and see FreeCAD as the best option for me, even if it suffers from the challenges of open source UI design.

Have you tried since the 1.0 release? There were quite a few improvements that were locked behind weekly builds for a long time. AstoCAD[1] might be another option for you. It's basically FreeCAD with a streamlined UI.

[1] -- https://www.astocad.com/

Maybe it's a local bump, but it sure seems like SQLite has become a fair more popular topic in the Rails world. I wouldn't expect to find it in a HN search tool. SQLite has gone from the little database you might use to boostrap or simplify local development to something products are shipping with in production. Functionality like solid_cable, solid_cache, and solid_queue allow SQLite to be used in more areas of Rails applications and is pitched as a way to simplify the stack.

While I don't have stats about every conference talk for the last decade, my experience has been that SQLite has been featured more in Rails conference talks. There's a new book titled "SQLite on Rails: The Workbook" that I don't think would have had an audience five years ago. And I've noticed more blog posts and more discussion in Rails-related discussion platforms. Moreover, I expect we'll see SQLite gain even more in popularity as it simplifies multi-agent development with multiple git worktrees.

Ouch. That sounds terrible with or without YAML anchors. GitHub Actions has overall been a great addition, allowing projects to integrate CI directly into their PR process. But, I never understood why it didn't have simpler paths for the very common use cases of CI and CD. Virtually any other dedicated CI product is considerably easier to bootstrap.

That's fair. And I'm not arguing that YAML anchors can never be a problem. I am saying that layering in a whole custom build system to handle a 250 line ci.yml file is not the trade-off I'd make. What I'd hazard to say most teams do in that situation is duplicate config, which is not without its own problems. I think YAML anchors is a fine solution for these cases and don't think they'll lead to total chaos. Alas, not all config options can be hoisted to a higher level and I'm trusting a team has explored that option when it's available.

If you're dealing with 10s of files that are 1000s of lines long, then YAML anchors may very well not be the ideal option. Having the choice lets each team find what works best for them.

Huh? I'm using YAML because that's the language used to configure GitHub Actions. You may not like YAML, and that's fine. But if we collectively had to learn the unique way each project generates their GitHub Actions config, that would be a massive waste of time.

YAML isn't that hard. Most GitHub Actions configs I see are well under 500 lines; they're not crumbling under the weight of complexity.

That would be better, but it's an option I already have available to me and it's just not attractive. AFAIK, GitHub Actions requires the config files to be committed. So, now I need to guard against someone making local modifications to a generated file. It's doable of course, but by the time I've set all this up, it would have been much easier for everyone to copy and paste the six lines of code in the three places they're needed. YAML anchors solve that problem without really creating any new ones.

If generating your GitHub Actions config from a programming language works for you, fantastic. I'm just happy we now have another (IMHO, attractive) option.

Oh, for goodness' sake. We know YAML syntax and that's the only part that's relevant here. Pointing out that different software uses different keys for their configuration or even takes different actions for keys that happen to share the same name isn't particularly insightful. We haven't been bamboozled.

Having used CI systems and application frameworks that support YAML anchors for configuration, adding in a programming language would be a massive amount of complexity for very little gain. We're not talking about dozens of locations with hundreds of lines of shared code.

Asking the team to add a new build dependency, learn a new language, and add a new build step would create considerably more problems, not fewer. Used sparingly and as needed, YAML anchors are quite easy to read. A good editor will even allow you to jump to the source definition just as it would any other variable.

Being self-contained without any additional dependencies is a huge advantage, particularly for open source projects, IMHO. I'd wager very few people are going to learn Dhall in order to fix an issue with an open source project's CI.

You already can set and read variables. The `matrix` section is often used to test against multiple versions of software. Environment variables can be referenced. And the project configuration supports both secrets and variables configured at the project level.

The argument that this is a security issue isn't very well fleshed out either. As far as I can tell, it boils down to his opinion that this makes YAML harder to read and thus less secure. But, the reality is we have to copy & paste config today and that's a process I've seen fail when a change needs to be made and isn't properly carried forward to all locations. I suppose I could argue that's a security concern as well.

Half the argument against supporting YAML anchors appears to boil down some level of tool breakage. While you can rely on simplifying assumptions, you take a risk that your software breaks when that assumption is invalidated. I don't think that's a reason to stop evolving software.

I've never seen a project use any of the tools the author listed, but I have seen duplicated config. That's not to say the tools have no value, but rather I don't want to be artificially restricted to better support tools I don't use. I'll grant that the inability to merge keys isn't ideal but, I'll take what I can get.

> Microsoft/GitHub has no model training. How do you think Copilot works?

I'm sure if you used that big, smug brain of yours you'd piece together exactly what I meant. Here's a search query to get the juices flowing:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Whether you agree with why someone may be opting to self-host a git server is immaterial to why they've done so. Likewise, I'm not going to rehash the debate over fair use vs software licenses. Pretending like you don't understand why someone that published code under a copyleft license is displeased with it being locked in a proprietary model being used to build proprietary software is willful ignorance. But, again, it makes no difference whether you're right or they're right; no one is obligated to continue pushing open source code to GitHub or any other service.

You’re assuming people are self-hosting open source projects on their gut servers. That’s often not the case. Even if it were, GitHub irked a lot of people using their code to train Copilot.

I self-host gitea. It took maybe 5 minutes to set up on TrueNAS and even that was only because I wanted to set up different datasets so I could snapshot independently. I love it. I have privacy. Integrating into a backup strategy is quite easy —- it goes along with the rest of my off-site NAS backup without me needing to retain local clones on my desktop. And my CI runners are substantially faster than what I get through GitHub Actions.

The complexity and maintenance burden of self-hosting is way overblown. The benefits are often understated and the deficiencies of whatever hosted service left unaddressed.

I’ve not heard of getstream. Is your service open source and all data easily extracted?

This post serves as a cautionary tale about how privately owned walled gardens, no matter how pretty, leave you in a precarious position. I suspect being in control of their data and having an open source escape hatch is what’s driving the adoption of Mattermost.

Truffle is not part of OpenJDK. It's a separate project and licensed under the Universal Permissive License: https://github.com/oracle/graal/tree/master/truffle.

The UPL is an OSI-approved open source license. It shouldn't be a problem to use in any setting, but you should check with your legal team to see what licenses are approved.