ecnahc515

Well uv runs on many systems and most don't have filesystem level dedupe configured, unfortunately.

Anyways it can be both? It could let the filesystem handle it if it detected the FS has file or block dedupe and fallback to hardlinks otherwise. It doesn't but that could be done if it showed it was worth it.

Notice rules are ordered. You don't optimize until you know you need it. They started with a data structure they though would be fine. Clearly it was fine since it worked and they decided it was later worth optimizing.

Because it would be slower and have different scaling requirements than the ones they want.

LSP isn't used for syntax highlights usually, that's still the job of the editor. This is where something like treesitter usually comes in. LSP is only used in this case for errors/annotations/etc.

Something like:

    OnCalendar=00/6

You can test it with:

    systemd-analyze calendar --iterations=6 '0/6:00:00'

The format is `DayOfWeek Year-Month-Day Hour:Minute:Second`

https://www.freedesktop.org/software/systemd/man/latest/syst...

I've been impacted by this particular "issue" and while it's changing the way "decades of convention" it's not really a bad thing imo. Running things via screen and tmux as a solution to background tasks has always been a huge hack imo. Not only that but the alternative approaches with nohup and disown also have their own issues. Imo it's actually pretty reasonable to need to work work the OS service manager to run background tasks, even with tmux and screen.

> The problem with systemd is that it's purposefully designed to be a viral monolith

Is it though?

Systemd is a project, not just a piece of software. It's got a lot of libraries that are reused across the different components that the systemd project ships. It's not that different from how most C/C++ projects have their own standard library built on top of stdlib/boost/etc. Any new "systemd project" could be done as a completely standalone piece of software, but it would mean recreating a lot of the libraries that already exist.

The biggest piece of coupling to systemd isn't really specifically systemd itself but how systems rely on how systemd does certain things, namely, cgroups. No one wants to manage cgroups themselves, so they use systemd to start services and put them into the cgroup hierarchy, etc. This is exactly one reason desktop environments "rely on systemd" (among others).

Why does everyone want to use cgroups (and thus systemd)? Because it makes managing groups of processes easier, which is directly tied to handling user sessions, which as it turns out, is something most applications want, since typically they deal with users!

Now, systemd's own sub-projects, (eg appd), are likely to be yet another consumer of systemd for similar reasons.

Using systemd, and building on top of it makes it much easier to implement features without having to do everything yourself.

Seems like the enactor should be checking the version/generation of the current record before it applies the new value, to ensure it never applies an old plan on top of an record updated by a new plan. It wouldn't be as efficient, but that's just how it is. It's a basic compare and swap operation, so it could be handled easily within dynamodb itself where these records are stored.

Also it's pretty likely it took less time than that to get an idea, but generally for public updates you want to be very reserved, otherwise users get the wrong impressions.

Sure they definitely were using Docker for their own applications, but also dotCloud was itself a PaaS, so they were trying to compete with Heroku and similar offerings, which had buildpacks.

The problem is/was that buildpacks aren't as flexible and only work if the buildpack exists for your language/runtime/stack.

Ah right, wrong linter. Thanks for confirming!

If the the OP is the author, did consider filing a bug with errcheck? It should be possible for errcheck to check if the comparison is being done within an `Is(err error) bool` method and skip the warning in that case, or even better: it could check if your using `errors.Is` within an `Is` method and warn in that case!

Cronjobs often run as root. If the host has is configured to send emails when a cronjob is completed it will default to sending it to user@domain where the user is the user the cronjob runs as, and the domain is what was configured in the cron configuration.

Instead it requires QEMU!

Oh, and since he's a public employee, you can look up the current salary and history.

https://hr.oregonstate.edu/sites/hr.oregonstate.edu/files/er...

https://www.openthebooks.com/oregon-state-employees/?F_Name_...

I'll summarize it:

$107k in 2017 and $124k in 2023. I don't know about you, but someone with 17 years experience could easily be making 2-5x that depending on the company and role.

I worked at the OSL as a student years ago, and it was one of the most impactful places I've ever worked at. I learned a lot, and I wouldn't be the engineer I am today without having worked there.

Since graduating, I've also hired, and worked with multiple alumni from the OSL and they're always top notch. Anyone looking for interns or new graduates with devops/SRE or SWE experience should be looking at the OSL for talent. It's not too often you can hire a new graduate with potentially multiple years of production experience, especially in devops.

In context of HN/Y Combinator, https://www.ycombinator.com/companies/coreos was a successful container/Kubernetes focused startup founded by two OSUOSL alumni, Alex Polvi and Brandon Philips, which was eventually acquired by Red Hat.

The OSL is something special.

For a list of projects the OSL helps host, check out https://osuosl.org/communities/. You might see a project you care about in that list! As an example: they provide aarch64 and powerpc VMs for a ton of projects to do their CI/builds on.

As someone who was a student at the OSL when Vagrant was hip, also thanks to Mitchell for creating Vagrant! We used it a ton for testing all our our configuration management.

That's 60% of the _budget_ not 60% of their time.

Also: Lance is almost certainly working more than 40 hours a week. Also, he isn't just a systems administrator. He's a mentor, fundraiser, any literally everything else that is needed to keep the lab running. There used to be more staff, but it's hard to retain qualified individuals. He's been there for 17 years, he's not doing it for the money, he does it because the OSL is important!

While this is great, for people claiming they can now built multi-arch images without emulation, how are you planning on doing so? As far as I know, if you want to build multi-arch images on native runners for each platform, you basically need to:

* Configure a workflow with 1 job for each arch, each building a standalone single-arch image, tagging it with a unique tag, and pushing each to your registry

* Configure another job which runs at the completion of the previous jobs that creates a combined manifest containing each image using `docker manifest create`.

Basically, doing the steps listed in https://www.docker.com/blog/multi-arch-build-and-images-the-... under "The hard way with docker manifest ".

Does anyone have a better approach, or some reusable workflows/GHA that make this process simpler? I know about Depot.dev which basically abstracts the runners away and handles all of this for you, but I don't see a good way to do this yourself without GitHub offering some better abstraction for building docker images.

Edit: I just noticed https://news.ycombinator.com/item?id=42729529 which has a great example of exactly these steps (and I just realized you can just push the digests, instead of tags too, which is nice).

Just a note that `x/sync` is not part of the Go std lib.

I almost never see bots close issues that are less than 30 days old. Many projects can change a lot in 30-90 days and the bug may no longer exist, keeping issues open when they may no longer be relevant isn't helping anyone either. If it is still relevant, it can simply be re-opened. I don't see any downside to semi-aggressively closing stale issues. If it's easily reproduced then most good projects will mark it so that it won't be auto-closed.

It's probably just because it's using reflection which is pretty slow in general. Lots of conditions/branches and boxing/unboxing of values.

> I actually wonder how much "overhead" a VM actually has. i.e. a linux kernel that doesn't do anything (say perhaps just boots to an init that mounts proc and every n seconds read in/prints out /proc/meminfo) how much memory would the kernel actually be using?

There's already some memory sharing available using DAX in Kata Containers at least: https://github.com/kata-containers/kata-containers/blob/main...

In log shipping cases it’s good as a buffer so you can batch writes to the underlying SIEM. This prevents tons of small API calls with a few hundred or thousand log lines each. Instead Kafka will take all the small calls and the SIEM can subscribe and turn them into much larger batches to write to the underlying storage (eg S3).

There's a book in the bobiverse scifi series that sort of covers this, very entertaining read!

Nothing about any of this is even close to zero cost.

Sure; but no kid is going to believe you; or even if they do; they won't care. It needs to be something they can put into action immediately and see results.

If you are watching your Linux ISOs on your self-hosted setup that uses a Roku; presumably they can still inject ads; regardless of where/how you obtained the media.

Many schools are starting later for this reason. Just because the bus may take long doesn’t mean there aren’t other issues that should be solved to make buses a more viable option.

Ollama is the Docker of LLMs. Ollama made it _very_ easy to run LLMs locally. This is surprisingly not as easy as it seems, and incredibly useful.