As long as people are aligned on advancing the Ruby ecosystem, I think it should be possible to cooperate even if there are disagreement in other areas [which political party you support, differences in personal opinions, etc].

Maybe it'll be resolved eventually, just like Merb <> Rails, Bundler <> RubyGems and RubyTogether <> RubyCentral were eventually merged. That's what I'm hoping for!

I've been trying to argue this point with my government several times (some MPs even replied friendly, so they'd actually read it, but still don't understand or believe it).

I Gitlab and Azure DevOps (also owned by MS) supports it, and even talked to an employee now working at Github, that implemented this in Azure DevOps.

More background: https://github.com/orgs/community/discussions/14863

With a semi-linear merge strategy, you rebase (without --fast-forward) before merging, so the history ends up looking like this:

    *   c8be0c632 Merge pull request #1538 from my-org/api-error-logging
    |\  
    | * 80ecc4985 Fix security warning, bump nokogiri
    | * 750613638 Log and respond with more detailed validation errors in the API
    | * 0165d6812 Log code and details when rendering an API error response.
    | * 1d4daab48 Refactor email validation result to include a descriptive message
    | * 635214092 Move media_type logging into context_logging
    |/  
    *   1cccd4412 Merge pull request #1539 from my-org/profile-clarify
    |\  
    | * 87b342a32 Rename profile default to migration target
    | * 2515c1e59 Fix disallow removing last profile in company
    |/  
    *   b8f3f1658 Merge pull request #1540 from my-org/customer
    |\  
    | * 064b31232 Add customer-specific taxed allowance reduction
    |/  
    *   3cf449f94 Merge pull request #1528 from my-org/console-logging
    |\  
    | * 99657f212 Don't log to rails console in production
    |/  
    *   8c72e7f19 Merge pull request #1527 from my-org/gemfile

Because I'm guessing allowing deletes would also make re-publishing possible, which would probably defeat the purpose. However, having them stick forever can also be annoying.

Comments URL: https://news.ycombinator.com/item?id=45039213

Points: 1

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=44796419

Points: 2

# Comments: 0

To me, storing and searching logs is quite different from most other search use-cases, and it's not obvious that they should be handled by the same piece of software.

For example, tokenization, stemming, language support many other things and are basically useless in log search. Also, log search is often storing a lot of data, and rarely retrieving it (different usage pattern from many search use-cases which tend to be less write-heavy and more about reads).

I know ElasticSearch has had success in both, but if I were Manticore/Typesense/Meilisearch I'd probably just skip logs altogether.

Loki, QuickWit and other such tools are likely better suited for logs.

- https://github.com/quickwit-oss/quickwit - https://github.com/grafana/loki

(both are also trying to replace Algolia, because both have cloud offerings)

Basically, the 'translate this' button you see on Twitter or Instagram next to comments in foreign languages. This API would make it trivial for all developers to add that to their web apps.

Safari/webkit is positive (though no official stance yet):

https://github.com/WebKit/standards-positions/issues/339#iss...

Rather, it's an API developers can use to add inline translation to web apps.

For example, under a comment in your app, you can (a) detect the language, and (b) if it's different from the current users/browsers language, offer to translate it with a small link (c) if the user clicks the link, the content is translated to their language.

https://oblador.github.io/hush/

I'm fine with a law saying Amazon is liable for fake storefronts etc. Sounds reasonable. I'd also favor requiring e.g. Uber or Airbnb to provide authorities with data to prevent tax fraud from operators in such marketplaces.

But to me saying Google's advertising product should enforce how the individual websites work [fingerprinting], is to me more in the direction of "an electricity provider should enforce how people live their lives in any home provided by such electricity…"

But when I read this it seems like they are unhappy with Google no longer enforcing their view of fingerprinting:

    We think this change is irresponsible. [...] We are continuing to 
    engage with Google on this U-turn in its position and the departure it
    represents from our expectation of a privacy-friendly internet.

There is a subtle but important difference here.

If governments enforce policy by bullying HSBC/Google/E.ON to enforce policies for them, there is no legal opportunity for companies and individuals to argue for their sake. You'll just be shut out of your bank/advertising/electricity for doing something "wrong".

If instead UK ICO would bring a legal case against an individual or company applying fingerprinting (and I'm no advocate of fingerprinting, but that's besides the point) then they can defend themselves in court.

- https://github.com/oxc-project/oxc

- https://oxc.rs

It's also what Rolldown (https://rolldown.rs/about) is basing their in-development bundler on.

A question out of curiosity:

Would you say that this is still a good fit for company-internal docker images?

I.e. a packaged rails app that's deployed in production using docker (to basically verify that we only deploy images built in CI [Github Actions])

Or would something more lightweight, like the Notary project[1], be a better fit for internal use?

(I know signing and provenance are different things, though for internal purposes, we can kind of infer provenance from just seeing a signed container, assuming we've locked down the build environment properly)

[1] https://notaryproject.dev/docs/quickstart-guides/quickstart-...

https://mise.jdx.dev/

It handles task running (wipe local test db, run linting scripts, etc), environment variables and 'virtual environments', as well as replacing stuff like asdf, nvm, pyenv and rbenv.

Still somewhat early days, tasks are experimental. But looks very promising and the stuff I've tried to far (tasks) works really well.

But it's still a good step towards more integrity in the software supply chain.

    We’re thrilled to announce the general availability of GitHub Artifact Attestations! Artifact Attestations allow you to guarantee the integrity of artifacts built inside GitHub Actions by creating and verifying signed attestations.

Comments URL: https://news.ycombinator.com/item?id=40791577

Points: 3

# Comments: 3