stevepike

Dependabot lets you know if a dependency you use has a vulnerability and opens a PR. The problem comes when teams are unwilling to merge those PRs even if tests pass. In my experience there's a very binary split here. Some codebases (especially open source libraries themselves) will immediately merge a dependabot PR if tests are passing. Many companies though find these PRs languish because they really need manual review to see if the change is safe and then an engineer needs to budget time in the case where it's not. These build up.

I generally agree with you, but I'd caveat that a critical CVE is easier to take if you're on the latest version of that dependency (so you can easily apply just the patch and not other changes). We want to help you weave package upgrades into ongoing maintenance rotations so that this is the case.

You mentioned that implementing an upgrade is difficult because of the actual code change but also the testing and identifying what the changes are in the first place. We're starting trying to do a really good job of the last one - what are the changes in this next version, are they breaking, do they break for your codebase, and what should you do if they are? We want to move from there to automating as many of the code changes as we can, but my sense is the biggest value is in giving you the confidence that we at least captured all of the changes you need to be concerned about.

Interesting. Should it? I don't have much experience installing ruby gems with the OS package managers, I've always done it through the language-specific ones like bundler / gem. Here's a github issue showing the kind of things that come up when the versions are mismatched: https://github.com/net-ssh/net-ssh/issues/843

Definitely. I'm very interested in govulncheck and building tooling into the ecosystem to make dependency use safer.

Thanks! We wanted to start with a language that's relatively consolidated around a framework before expanding to more balkanized ones like JS.

Can you expand a little? Here's some technical background on what we're doing:

We have our own database of every version of every rubygems package alongside its runtime dependencies (like you see at https://rubygems.org/gems/pundit).

Then we parse your Gemfile and Gemfile.lock. We use the Gemfile to figure out gem group and pinned requirements (we run turn your Gemfile into a ruby AST since Gemfiles can be arbitrary ruby code; we use bundler's APIs to parse your Gemfile.lock). This gives us all of the dependencies your rely on.

Then we let you choose one or more package that you want to upgrade and the version you want to target (let's say Rails 7.0.4.3).

Now we have [your dependencies and their current versions], [target rails version], [all of the runtime dependency constraints of these gems]. We run this through a dependency resolution algorithm (pubgrub). If it resolves then you're good to upgrade to that version of Rails without changing anything.

If this fails to resolve, it's because one or more of your current dependencies has a runtime restriction on rails (or another indirect gem being pulled in by the new rails version). This is where the optimization part comes in. The problem becomes "what is the optimal set of versions of all your dependencies that would resolve with the next version of Rails". Currently we solve for this set trying to optimize for the fewest upgrades. As our dataset of breaking changes gets better we'll change that to optimizing for the "lowest effort".

Happy to elaborate.

Only Ruby right now. We want to make it work really well for one language before expanding. Which language would you want it in?

We have a command line tool you can use to send your lockfile to our server so we can process it, but you have to use our web app to view the results.

Thanks for the feedback. We know we're tackling a big problem here. Our ultimate goal is that if you use Infield we keep you on the latest version of every dependency, automatically. The road to get there can go a number of ways.

> My biggest pain isn't with the plan. It's with the actual upgrade process. Things _always_ break. Every single time we do a major upgrade, there's this long tail of things we need to fix. Even worse is the undocumented changes that break. This gives me nightmares.

Planning is one way to make those major upgrades go wrong less often. Our idea is that we can break large upgrades down into incremental changes that are individually safe and mixed in to your regular dev cycles, so that when you go to do the large upgrade you're not making such a big change all at once. This means things like fixing every deprecation ahead of time and making sure all the other dependencies you use are compatible with the version you're upgrading to.

We're calling this "upgrade paths" in our tool. Something like a major rails version upgrade is terrifying because of all the moving parts. Often you may have a dozen other gems that need to be upgraded in order to upgrade Rails. You said "If I can incrementally upgrade one package on every PR until I'm up to date, that'd be amazing.". We want to make that the flow for major framework upgrades, so you're merging in incremental improvements in the blocking dependencies ahead of time.

Undocumented breakages are for sure on our roadmap. We have two types in mind today: - Changes that are missing from the changelog - Incompatibilities across gems (for instance there was a time recently where if you had both datadog and newrelic installed and used elsaticsearch upgrading the newrelic gem would break prod)

We have some ideas on how to figure this out automatically (like reading code diffs with GPT rather than just changelogs), but the best way is to see upgrades out in the wild. As we see more and more upgrade experiences from our customers we'll be able to catch these issues and build this dataset.

I'd love to hear other ideas for making major framework upgrades safer.

> * It ran the repo's test suite against progressively newer versions of dependencies. Showing when and where unit tests fail.

Would this be something like `git bisect` for upgrades? We run your CI to figure out where you can upgrade to without something breaking? We're trying to figure this out statically by reading changelogs and building up a database of breaking changes. Our roadmap is to make this database better over time by pulling in more and more undocumented changes (by seeing customer upgrade experiences and by sourcing information from places like github issues). In my experience it's more common (and much more dangerous) that things break when your dependency changes in a way that wouldn't be caught by CI.

It's a bit buried, but if you go to https://app.infield.ai/hn and click "I don't use Ruby" we'll ask for your email/language and put you on our list.

Thanks! We actually pivoted to working on this problem at the beginning of last year. We were previously called Syndetic and were building software for data providers. As we considered pivoting I spent some time thinking about the biggest problems I've faced maintaining software and started doing personal consulting. I upgraded a bunch of Rails and React apps for various companies over the course of 2022.

Toward the middle of last year I re-connected with Andy (our third cofounder) who I went to school with and have wanted to work on a company with for a long time. We did a bunch of customer discovery / product work to figure out how to take what I learned doing this by hand and turn it into a software product. That was exciting enough that we decided to bring Andy on as a third co-founder and pivot our YC company.

Allison and my background is in building data businesses. Before Infield and Syndetic we worked at a startup in the beverage industry where we standardized inventory data for every alcohol product sold in the US. As we got into building Infield we didn't expect to use LLMs at all. We imagined a similar human-in-the-loop expert system to what we've built before.

I've been extremely impressed with recent language model's ability to handle unstructured changelog text. For example, consider the following snippet of a changelog:

  Security:
  - Address an issue with password validation

  Breaking change:
  - The `foo?` method now returns a boolean instead of int

Language models can carry the context through, so we are able to not just parse this apart into discrete changes (which I could figure out how to do with a regex) but also bring in context and categorize them. It can do this generically and really feels like something new.

(founder here). The interaction between high level language package managers and system binaries or compiled extensions is definitely on our roadmap. For example the ruby net-ssh gem relies on specific versions of openssl being compiled on the machine. Do you think this is particularly difficult in ML?

Is your frustration mostly from needing compile all this non-python stuff across environments?

Infield (YC W20) | Remote (USA) | Full-Time | https://www.infield.ai/

Infield helps software teams keep their open source dependencies up to date. We’re automating away the toilsome work of reading changelogs, assessing risk, and upgrading packages so that software teams can focus on shipping features. We’re a small team of repeat founders passionate about making open source easier to use.

You’ll be helping found our engineering team with the opportunity to take ownership of large pieces of our technology stack. We're building in a wide range of areas - from large language models to complex data pipelines to modern, interactive web front ends - and want people who are excited about learning new technologies and passionate about open source.

Role: Full-stack founding engineer Stack: Ruby on Rails (with turbo for the frontend) and Postgres

You can email me at steve (at) infield.ai

I think about this quote sometimes: “It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so. “ – Mark Twain

I don't know why people are picking on your specific search. Try turning off your ad blocker and searching for "zoom download".

I still use wobbly windows on KDE and it fills me with warm nostalgia.

Can you explain the screen tearing thing? I'm running kwin on X and I don't notice any screen tearing (including doing things like moving windows around rapidly with the "wobbly windows" effect on).

Yeah, here's where I think things tend to go off the rails in the wayland discussions with people having different personal experiences. I've tried to run both firefox and chrome in the native wayland mode and neither works properly _for me_. I forget what the chrome issue was, but in firefox on KWIN if I enlarge a window the portion of the window that was added doesn't render properly --- it's a flashing white rectangle --- and then if I resize it down it either crashes or garbles the whole window. I'm sure this doesn't happen to everyone.

Is the scaling algorithm specific to the wayland implementation? I saw a github thread about configuring it in sway but wasn't able to find anything about KWIN. I'd also love a flag to just disable scaling on a per-xwayland-app basis (so I could use the --force-device-scale-factor hack) but couldn't figure out how to do that so if you know something off the top of your head it'd really help out.

Anyway thanks for the tip!

Ok, here is my use case that wayland doesn't work for. I have an AMD graphics card (5700xt) and two 4k screens. I want to run firefox, chrome, emacs, and a terminal.

Using KDE or Sway, if I set my desktop scaling to 2x, all programs that run through XWayland have extremely blurry display (they've been rendered at 1x and then crudely scaled up). This includes firefox, chrome, and emacs. The browsers have ongoing work to support wayland natively, but neither is stable for me.

If I set my desktop scaling to 1x, I can then scale up individual xwayland programs with flags like `--force-device-scale-factor` if they support them. This gets me close to the behavior on X but on X I can just set a global 2x scale.

I totally understand the frustration of OSS maintainers when people demand they fix things with no intention of getting into the code. On the other hand, the marketing behind wayland encourages some unrealistic expectations. I went out and bought a new graphics card and it turns out I can't even run firefox! That was not what I expected to happen.

Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.

As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the method where you set up a network firewall at the router level that redirects all port 53 traffic to the pi. It's a nice feature for getting my xbox filtered, but it really felt like an insecure historical quirk rather than a feature we should be praising.

Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?

I just want to chime in and say you probably don't want to do this. Steam on linux can technically work with NTFS drives, but I've only had success running games that are linux-native. With anything that uses wine behind the scenes there are problems relating to file permissions.

I gave up and just created an ext4 partition and things got a lot more stable.

I think printers bring out a strong reaction in many of us that paying so much for inkjet refills is an affront. Even if the absolute amount of $ isn't that much HN is generally of a demographic that doesn't want to feel trapped into overpaying for anything related to tech.

I can only speak for myself, but as someone who needed a printer for the first time in a while due to the pandemic, I bought a used brother laser printer (HL-2170W) for $20 from someone local. It's not perfect, especially with network printing from a linux client over wifi, but I was able to get it all set up and refilled the toner with a very cheap generic from Amazon. It feels like a device I "own" rather than some black box I'm renting from HP.

I don't know where the excitement around buying the new ones comes from. When I looked it was hard to find them in stock and they didn't seem particularly inexpensive.

Sorry I didn't mean refilling the existing cartridge. You get entire replacement cartridges like https://www.amazon.com/dp/B07C3X6HFG

Second this. I don't know what toner prices are over there but I've got a used Brother HL-2170W that I got for $20 and it works great from linux, mac, and windows. I've been able to refill it with generic toner @ $25 / two pack.

There are fancier modern things but https://cr.yp.to/daemontools.html still works great for keeping a simple script running.

Extremely slow for me as well (with a fast machine) on Arch linux in both firefox and chrome.

Getting about a million "Access to fetch at 'https://example.com/' from origin 'https://map.mta.info' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled."

I run KDE with two 4k screens and there are two things that don't work as of 2020.

1. X can't handle independent screen scaling of two different DPIs. I have 24" and 27" screens and on windows I can have the 24" one at 2x and the 27" one at 1.5x and it "just works". In X I have both at 1.5x.

2. Wayland supports independently scaling the two screens. Unfortunately programs that don't support wayland run through something called XWayland, which upscales them in a crude way that makes the fonts blurry. It's pretty much unusable because of this to have an XWayland app (this includes chrome, firefox, and emacs) running on a 4k screen in wayland, at least on KDE.

It's frustrating because it's SO CLOSE. There are WIP branches of both browsers running on wayland (but they're not stable for me) and once those land I think everything will finally work.

All this said I do still use KDE on X daily as my development environment, but every time I boot back into Windows I'm frustrated again by how much better the scaling is.

Yeah, there's a whole category of apps that run on heroku with maybe 10 dynos tops that could definitely be deployed on kubernetes with manual / web ui-based configuration.

The most infuriating part of this is that they haven’t implemented a functional deep linking system. I mostly come across Reddit on my phone from google, and would happily use the app to read whatever page I’m trying to get to, but the “open in app” button opens the App Store (even with the app installed). This is on iOS, maybe android is better.