c0balt

I'm sometimes amazed by project sizes, a 30k line codebase is small? I'm aware that the ceiling is high but 30k lines of code can encode so much information and behavioural nuance.

Maybe this is just my backend/network focus with Golang though. Scaling beyond 10-15k lines of code always was quite intimidating as it is usually where I lose the ability to just keep a model of the codebase fully in my head.

Many distros deal with the problem of learning about these issues the same time as the public. Some have fast track processes to ensure patches can get into their stable/rolling releases but it is still a lot of work (especially as kernel updates usually mean that automatic updates won't fully shipped you (without alsp automatically rebooting after an update)).

I don't know, my Windows 11 setup does not use FDE (afaik). It is exclusively for games which require kernel level anti-cheat with secure boot.

However when I setup Windows it wiped my TPM keys for LUKS so maybe there is a potential conflict there.

It already has official packaging for Tumbleweed, see https://github.com/mullvad/mullvadvpn-app/issues/2242 for the upstream issue. Leap can use the normal Linux application, you will just have to provide the dependencies yourself.

The page linked above contains links to their bootloader and Linux kernel tree (6.1 apparently), so chances are rather low.

Lanzaboote is great, I've been using it for almost a year now in a dual boot with Windows 11 for full secure boot on my desktop. It is quite stable (notably was set and forget) and the initial setup was relatively easy.

Not damaging their relationship with Google as a vendor most likely. For better or worse, GrapheneOS is depend on Android which is controlled by Google.

I feel for the people living there and being affected by the pollution. The long term effects of chemical pollution are ugly.

But the CEO in the intro just seems like an odd choice. PFAS were known to cause issues for a long time, if you continued to use them for years then it is in your back too.

Being "surprised" this might eventually affect your own product line just seems naive. You might have trusted 3M but just blindly trusting a supplier is not an excuse at some point.

Yep, that is accurate. There is also a command/API route to find the path on disk iirc.

In my setups it just was easier to use fixed paths (or relative to project dir) from a permissions management perspective. Backup tools did not always have to/should run as root which is helpful on machines providing multiple distinct services.

Putting borg or a similar tool in a container that is part of the compose manifest file can also help. I haven't seen this used in practice though yet.

Ime, the only useful product tours where in games, I. E., tutorials. This usually extends up to in-game hints at certain features like a characters ability. A lot of software can probably pull inspiration from there in regards to including hints with minimal interruption during usage (tooltips that are shown longer the first time you use something etc).

The "easiest" way is to use bind mounts to a local directory (or multiple directories) instead of volumes. Then you can just use normal backup tooling.

Docker volumes (and bind mounts) however have the minor problem of being hard to get a consistent copy to without stopping the service. You can work around this by, e. G., having ZFS or btrfs as the underlying FS and making a snapshot there. Otherwise, your software (like PostgreSQL) might also have other online backup tooling.

There is also a minor incentive problem here, mainly that a landlord can/will often offload the running costs, Nebenkosten, to the renters indefinitely.

That means they are sometimes economically incentivized to choose an option with lower initial cost but a higher running cost. Governments can/do bend these incentives via taxes but it can be hard/expensive to renovate old complexes (and that part cannot directly be offloaded by the landlord).

If I have you hammer with a wax coated handle then it will regularly slip out of your hand.

One could blame the user for not "just" holding it right. Or alternatively reconsider if the handle should have a grippy coating instead.

I had this nic on my laptop and a desktop, it is genuinely a pos. I'm always kinda surprised that a driver was borked given the very widespread use of it the hw+driver combo though

(and as a side-note, the in-kernel driver also has some problems. Ime, it sometimes dropped one of my nics for no apparent reason until the next reboot. It is better than the out of tree one though)

Growth hacking at its best /s

A vulkan computer shader is more portable, chances are also that the tooling for it will still be supported in a few years for your GPU (which isn't a given for ROCm especially when dealing with consumer cards)

Short answer, no.

There are better learning resources and a better ecosystem available around Nvidia cards & software (cuda).

Long answer, it depends. It will add more challenges and require significantly more effort (even outside the GPU programming itself, debugging toolchain etc. is a somewhat separate skill). The smaller/less mature ecosystem also means you will have less examples to look at for references.

The main difference that Denuvo does nothing to improve the experience of the end user.

I don't like Anti-Cheat solutions with elevated privileges but they have (at least for some time) reduced the number of Cheaters in games like Valorant or BF, for most users this is at least a somewhat understandable tradeoff. Denuvo on the other hand is DRM and a pure tradeoff in favor of the publisher at the cost of the consumed.

The goal (ATP) is similar but the idea is a bit different, sledgehammer is not directly learning/applying rules but instead effectively a driver for invoking a bunch of ATPs + SMT solvers at once on a goal in Isabelle/HOL.

You can read more about it here: https://isabelle.in.tum.de/dist/doc/sledgehammer.pdf

The current GUI interface is Isabelle/jedit. Afaik, no Emacs interface is officially provided atm.

Isabelle/HOL as a language is nice, but the tooling has deep flaws even outside the pure desktop-first app approach.

The language is different (not necessarily better) in comparison to Lean, but I do agree with some of the points on dependent types. It seems both languages mostly just made different tradeoffs, which imo, were fair and have shaped them into quite efficient tools for their domains. The domain of "proofs" is large and different paradigms just have different strengths/weaknesses, Lean just specialized for a different part of this space.

Sledgehammer is nice but probably just a question of time until an equivalent can be ported/created for Lean. It might also be nice to use for explorative phases but is a resource hog, it also makes proofs concise but I would usually rather see the full chain of steps directly for a proof in the published code instead of a semi-magic "by sledgehammer".

Working on Isabelle itself however is painful (especially communicating with developers) in comparison to Lean. Things like "we don't have bugs just unexpected behaviour" on the mailing list just seems childish/unprofessional. The callout to RAM consumption of Lean and related systems is also a bit of joke when looking at Isabelle's gluttony for RAM.

It is reasonable to ask for a follow-up project/fork to take a different name. Naming your project, e. G., pgbackrest-ng, does not sound too onerous of a requirement and clearly communicates to users that maintainers have changed (see also paperless ng/ngx as good examples of such a change).

Finding a successor is also not easy nor cheap (in regards to time).

A simple yet almost hard to imemt solution (given the view of an outsider on most U. S. cities respect for bicycles) is to "just" provide actual, hard seperation for the bike lane.

This can done with carve outs/ gaps for public service buses, a somewhat cheap implementation are Pop-Up bikelanes but concrete barriers of 10-15 cm also do the job well.

> Why is it always these efforts are little private things or not for profit initiatives?

Because (relatively) small teams can act faster. It is also a lot easier to have a small, motivated core group with shared objectives and aligned vision of a project. A non-profit/public benefit entity is also a reasonable host for such an effort. Such projects can also tap into public money (under particular circumstances) via the various EU and national grant schemes.

> Just have it be an official EU government backed identity.

The amount of baggage this would entail is quite large. Besides just bureaucracy you almost certainly would then also invite politics even more, because, even for small projects, the next question will be: In what countries is the service hosted and by which agency/developers?

That is besides the almost inevitable inefficiencies for resource usage and other obligations from being associated with public funds (which can require a LOT of internal politics work to acquire and especially retain).

The scope/feature set of both is just quite a lot wider, from IDEs to an ecosystem of 1st and 3rd party libraries and extensions. The rendering engines and their capabilities are also quite different (with Unreal and Unity both being quite a lot more advanced).

The IPv6 for the overlay is neat. I won't use it probably (as my number of hosts is <100) but I would prefer better support for dualstack underlay.

Maybe this is just my interpretation but OP effectively argued "too many ineffective meetings, we should have less unnecessary meetings and a clearer, independent direction".

The commenter above argued that the problem was slightly different, it's not too many meetings for communication but too many that are not achieving effective communication. A meeting in itself does not create communication (of information and exchange of opinions etc.) and the commenter wanted to increase the number of meaningful meetings instead of/in addition to just cutting down meetings by numbers. The criticism of not enough time spent on communication is in the same vein, both agree on the issue of "too many unnecessary meetings".

One could reconsider whether building your business on top of a model without owning the core skills to make your product is viable regardless.

A smaller builder might reconsider (re)acquiring relevant skills and applying them. We don't suddenly lose the ability to program (or hire someone to do it) just because an inference provider is available.

Run on premade, static tracks with clearly divided "roads" from the rest of road participants.

Their role is to stop the train in an emergency and adjust to speed etc. to track/driving conditions.

Automating their job probably wouldn't even need the complex ML used for self-driving because the context is significantly simpler and relatively well defined. Maybe a team in city might need such a model but it would still be a significantly simpler task than driving a car.

Or the most likely more expensive rate limiting (computational wise)