nirvdrum

Microsoft already switched its release support to the "series" model. There are still big games coming out on PS4. With the PS6 expected to be very expensive, we may very well see games simultaneously released on the 4, 5, and 6. We may be moving away from discrete console generations. Older consoles still have a massive library you can cycle through as well.

Yeah, the console companies want to be profitable, but consumers are pushing for new stuff, too. I don't care a whole lot about graphics improvements, but going from HDDs to SSDs was a huge improvement and worth the upgrade for me. And software engineers as a whole have long favored requiring new hardware over optimization for current hardware. I hope the great electronics crunch will curtail that.

Come on now. This is extremely obvious.

I was talking about game compatibility and you brought up an utterly unrelated point and referenced non-specified “recent moves by Sony”. Forgive me for giving you the benefit of the doubt and inquiring if there were platform changes that would affect compatibility.

Clawing back games isn’t a particularly new risk. If you issue a chargeback, Sony bans your account, losing your library and any wallet funds you may have. And I already indicated that if I have to go all digital, then Steam is far more attractive. But there’s no guarantee any given game I buy on Steam is going to play on any given device. If I purchase a PS5 game I can be fairly certain it will run on a PS5 and what the performance is going to be like.

But, yeah, thanks for reminding me: physical games are still a major benefit for consoles. I buy Switch cartridges almost exclusively because Nintendo's DRM implementation is horrible for a family library. I lend games to friends and family members. I've even sold games and bought used ones. Steam Family is great, and the best of the current DRM options. But, while physical still exists, it's a good reason for favor consoles that has nothing to do with technical acumen.

Can you please elaborate? The recent moves I’ve seen have been announcing a shift to digital-only and another about clawing back movie purchases. Neither are appealing to me, but also aren’t related to game performance or compatibility.

I don’t think the appeal is just to the less technically inclined masses. I’m a developer with a MacBook Pro and a Linux workstation. Proton has come a long way, but consoles just work for the most part; I never have to question whether the game will function and perform well on the console (setting aside the random buggy messes we see).

Then there’s the convenience. I don’t want to play games where I work. I want to play on my TV. I have no interest in moving my workstation into my living room. Streaming with Moonlight works well enough, but there’s still lag. Even if I wanted to move my PC to the living room, the setup isn’t as nice. The Steam Machine has HDMI CEC and can power on with a controller — all the major consoles have had that for years.

Even if I accepted all that, no one else in my household could play anything while I’m working on my computer.

Things are a little weird now. If I’m going to have to go all digital, Steam Family is by far the best option of those with DRM. But, due to the astronomical cost of components, consoles are still pretty attractive.

I’ve regularly used an M1 Max, M4 Pro, and M5 Max. They all get pretty loud when driving local LLMs. “Jet-engine” would be hyperbolic, but it’s definitely noisy.

He didn’t ask for it, as far as I can tell. It looks like a Rovio customer asked how they treat downstream partners. I think that’s allowed under capitalism.

Be that as it may, plenty of engineers don’t understand the full ramifications of their open source license choice. Undoubtedly some, if not many, regret it afterwards. Companies change the terms or revoke licenses all the time. But, the dumb, naive engineer that gave their work away didn’t pay a lawyer to advise how to best give their work away, so screw ‘em.

If I made a boatload of money on the back of someone else’s work, I’d reward them. You wouldn’t. Neither one of us is legally required to. I’m not fond of taking advantage of people that don’t realize their worth. And I think the whole open source thing works best giving and taking, whether that’s code, money, or time.

But, this cutthroat approach to open source also hasn’t always been the societal norm. IBM and others made sizable donations to groups like the Apache Software Foundation back in the 90s and 00s and were more or less expected to do so. It seemed to me more a case of both sides agreeing a bunch of money could be spent on lawyers to iron out whatever terms or we could keep the licensing simple and have a gentlemen’s agreement on how to conduct ourselves. I’ve never heard of the Box2D guy so I hope that fame was worth something. It sounds a lot like being paid in exposure.

To your point, I don’t know how to codify a “leave a penny, take a penny” approach to open source and really don’t have the inclination to spend either the time or the money on a lawyer to figure that out. So, nowadays I just don’t release open source code anymore or, if I do, it’s AGPL just so I can protect my interests. I don’t think I’m alone in this. The camaraderie aspect of it has been supplanted by maximum value extraction and I don’t think that’s really sustainable. But between LLMs and an endless source of naive optimists, maybe this is fine.

You can’t export save files on PS5. You can’t transfer licenses, so you’ll have to repurchase any games you want to continue playing. For trophy/achievement hunters, those are going to be locked away. And a lot of the online game accounts are locked to the platform so you’ll have to start any progress/reputation/level over.

Yeah, you can walk away, but let’s not pretend it’s the same thing as buying orange juice at a new grocer because your regular one only sells it with pulp now. People aren’t being irrational in being annoyed by this.

Probably USD vs CAD. The parent posted a /ca/ link, which will look really similar to /us/, but the prices will all appear to be higher.

Part of the point the article makes is that most other popular languages have a comprehensive standard library. JS has an astonishingly small on. Rather than have one vetted set of libraries that ship with the language, applications either need to roll it themselves or pull from a 3rd party package repository. We've drilled NIH into people, so they tend to reach for packages. That's not necessarily a bad thing, but it often means they're pulling in more code than they need. The JS ecosystem has also favored smaller modules, so you need many of them. And everyone builds on top of that, leading to massive growth in dependency graphs. It's a huge surface area for things to go wrong, intentionally or not.

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.

The lack of a comprehensive standard library for JavaScript also results in projects pulling many more third party dependencies than you would with most other modern environments. It’s just a bigger attack surface. And if you can compromise a module used for basic functionality that you’d get out of the box elsewhere, the blast radius will be enormous.

They’re definitely playing catch up, but the IDE integration makes interactive development really nice. Claude is good for one-shotting things, but I find JetBrains AI integration really useful for working with large codebases where I may be unfamiliar with things.

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.

Based on another reply I can’t tell if there’s a clever window-based pun that I’m missing. If not, I think you want “shudder” and not “shutter” here. I’m sorry if I just ruined the joke.

CheapCharts is really nice. I find discovery in the Apple TV store pretty bad otherwise. They earn their affiliate revenue.

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.

After getting scammed on Facebook Marketplace, I look at the profiles of sellers, particularly if they don’t have much in way of reviews. That seems more prudent than creepy to me. I’m not stalking anyone and I’m not looking to be their friend.

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.

In case anyone's wondering, the TruffleRuby project is still going strong. It undoubtedly would be going stronger were Chris still with us. But, some of us that worked with Chris in the early days of the project and others that joined later are still pushing the project forward.

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.

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/