nightpool

Many distros come with Ruby standard, it's not very big and I think it has a lot to recommend it over Python or Perl when it comes to lightweight scripting for sysadmins and day to day automation. I wouldn't necessarily pull it into an open source project where they weren't already present, but I would definitely choose it for personal use well before Python or Perl

Ruby is my favorite shell scripting language, I used it last year for a complex ffmpeg automation script (use blackdetect to detect long stretches of power-off and split a video file into much smaller components), and Ruby made it a breeze when I know it would have been a real struggle to get working in bash or powershell

Do you have a link to the Chrome site-specific patches directory? As you can imagine, it's pretty hard to search for :P

Because HN's development prioritized "good for the user" over "good for browser developers". https://www.w3.org/TR/design-principles/#priority-of-constit... https://datatracker.ietf.org/doc/html/rfc8890

Anyway, the "errors" that OP mentions are simply just deprecated attribute styling and like, one or two instances of center tags. Hardly breaking anybody's back to continue supporting those.

I mean, it's explained very clearly in the commit message that's linked?

    Since the page where the bug manifests itself already has responsive CSS
    styling, we can quirk TextAutoSizing to skip adjusting for it, at least
    until we figure out why we are calculating RenderBlockFlow width inconsistently:
    https://bugs.webkit.org/show_bug.cgi?id=275223

That's even better than a comment, because you can git blame for it and get the full context of the issue (from the bug thread that proposed it to all of the documentation of the investigation done for both bugs)

ROS is one of those "frameworks" that's so awful and pervasive that for teams of more than 2 people handrolling your own networking is almost always going to be better than trying to make ROS work.

This is why I said "your cloud provider". If you're handling your own physical devices, yes, YMMV. (For example, FDE on company laptops should obviously be non-negotiable). But expecting it to do anything else is just magical thinking.

Encryption at rest is something your cloud provider does to pass SOC audits. End of sentence. If you have stronger security concerns, then you need to turn to other tools in your toolbox.

Isn't that exactly what numpad0 said? You're just agreeing with them.

That's the case in many common/similar agreements, but the OpenAI agreement is different because it's specifically clawing back already vested equity. In this case, I think the consideration would be the company allowing transfer of the shares / allowing participation in buyback events. Otherwise until the company goes public there's no way for the employees to cash out without consent of the company.

Some kind of end-to-end team encryption would be great, I could generate a local passphrase using 1Password or something and put it in the team vault. Then you wouldn't have access to the request metadata (maybe outside of hostnames?) on your servers. Alternatively, an option to simply download local replays and then a desktop/electron viewing client instead of having to upload them to a server would be great too

Apparently, the exact same year.

Google is your friend

In this case, the Piet palette uses about 8 different colors and 3 different "steps" of luminance, so it seems hard to mess it up too much even if it's based more on a human understanding of colors then a mathematic one (orange -> orange, light blue -> light blue, dark blue -> dark blue, white -> white, etc).

It's also interesting to note that, for Piet, the colors themselves don't have any particular meaning, the instructions are encoded by the differentials between one color and the "next" color in the program direction, with blocks of continuous colors encoding noops. So moving from red to light red is a [0,-1] change, (no hue, 1 step lightness), and moving from blue to dark red is a change of [4,1] (4 steps of hue, 1 step of darkness). So the exact colors don't matter too much

I think the issue in this case is that the Perl programs were "really" created by OCR hallucinations, not graphic artists. Piet, on the other hand, is really executing the painting itself.

Piet is from 2009, at least. Although this page was last updated in 2018 with some new links i don't know if having the (2018) title makes sense, it feels kinda misleading

> If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame.

Why? What's the downside to reusing grid-column-template or whatever for the CSS Masonry spec?

Please please please support pasting images! Any form field where I have to select a file from my filesystem instead of using my paste buffer increases the friction of using it like, 5x. (This applies to every image upload button I've ever used)

And it worked out super well for everybody in 2021 :)

Thanks!

This is a good amount of data but is $100 really the right cost for the replacement of a table saw if the saw itself is actually damaged, as OP says? Is it your experience that the saw is almost never damaged and the replacement cost is almost always the ~$150 dollar blade, or do you know how frequently these false firings damage the saw as well?

"We can attach a shop_id to all shop-owned tables and have it serve as a sharding key. Moving a shop from one shard to another involves selecting all records from all tables that have the desired shop_id and copying them to another MySQL shard. For this post, it’s helpful to think of each pod as a MySQL shard."

Sounds like this is just normal sharding. Completely different from having a totally separate schema like GP proposes (with that approach you don't use sharding keys at all).

Reported where? Does that include a monolithic "free tenant" that would be larger than thousands of their other tenants put together? Every Figma user has their own personal workspace along with the workspace of any organizations they may be invited to

That's still 2 orders of magnitude smaller than the scale of Figma—they would need to somehow manage millions of Postgres schemas. I don't think it's a realistic possibility

Figma has millions of customers. The idea of having a Postgres pod for each one would be nearly impossible without completely overhauling their DB choice.

I think you took away the wrong lesson, personally. The point is that no single metric or even group of metrics is going to be able to cover the entire reality of what's important about a database, even when what's important is performance. Just focusing on metrics is not enough. The post gives other examples about times when e.g. clean, maintainable code matters more (DuckDB) or how there are fundamental architectural limitations that make "worse performing" databases better for what you need (e.g. Clickhouse not being good at joins, some DB's friendlier SQL and CSV parsing all come up) but the message that unites all of its examples is "benchmark performance, even on very well-designed benchmarks, are often misleading to the actual reality of using a database".

Also perfectly describes their business contracts for e.g. Workspace. A great core product wrapped in a worse-than-useless "support" contract through some of the worst consulting firms in the world skimming 15% or whatever off the top.

The major competitors include Fabric and Forge, with each being distinguished primarily by the type /amount of extensibility they offer. Paper is focused on "backend only" modding (plugins), as opposed to the "full spectrum" modding supported by Fabric and Forge that often (but not always) require users to download the mods on their computer as well.

From that perspective, Paper is much more commonly used by commercial server owners (since they're catering to the very large audience of casual users who don't want to install mods) and casual users paying for a server host for their friends who just want a couple of small tweaks, while Fabric and Forge are generally used more by smaller groups of dedicated power users who want a lot of extra mods

Paper and Forge both focus primarily on providing a large extension API through modifying the decompiled Minecraft source code, while Fabric takes a different route by providing primarily an extensive dynamic Java bytecode modification library that allows developers to effectively "build their own API" by modifying the vanilla Minecraft classes at runtime. This means Fabric is generally much faster and easier to update to newer versions, and most smaller mod developers have adopted it as their preferred platform of choice due to the more powerful tools, and use open source libraries to make up for the lack of a built in API. (These are generalizations, of course, and Forge and Fabric have experienced a fair amount of convergent evolution at this point as well.)

On the performance side, there's a new experimental Paper-like server called Folia from some of the core developers aimed at providing radical parallelism. Normally, all Minecraft servers run their main gameloop on a single thread, and the largest of server operators deal with the issue by providing front end proxies that shard users to different servers, which limits interactivity. From a technical complexity level, you could almost compare it to a GIL-less server reimplementation. All, again, built as patches onto the decompiled Minecraft source code. It's gaining more stability and has been used in some very exciting public tests

I mean, for HTTP Basic there literally is a single canonical string, and it's not uncommon to see people send you links like https://user:somepasswordhere@example.com.

I think the arguments other commenters have made about logging, browser history storage, etc are more convincing