I totally agree.
If one needs to put metadata in commits, usually better to just put it in a Git trailer.
https://git-scm.com/docs/git-interpret-trailers
`Co-authored-by: Alice` is a common one, but you can have anything in there.
HN user
::1
I totally agree.
If one needs to put metadata in commits, usually better to just put it in a Git trailer.
https://git-scm.com/docs/git-interpret-trailers
`Co-authored-by: Alice` is a common one, but you can have anything in there.
I understand forking is sometimes needed, but it's also somewhat discouraging to see that the differences couldn't be reconciled.
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!
This is the part that I think most politicians simply don't understand.
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).
Does anyone working at Github know why 'semi-linear' merge isn't supported as a merge strategy in the merge queue (and regular PRs)?
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
It makes it easy to look at the Git history both at the 'PR level' kind of like a change log (`git log --merges --decorate --oneline`) or dig down into each PR to see all commits.Does anyone know if immutable also means I cannot delete a release? (even after say 3 years)
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.
"What are your main use cases for search or log indexing?"
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
For anyone who's interested, two other popular contenders for replacing Elasticsearch are Typesense (https://typesense.org/) and Meilisearch (https://www.meilisearch.com/).
(both are also trying to replace Algolia, because both have cloud offerings)
This would be very useful.
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.
I honestly don't understand the arguments Mozilla have against it.
Safari/webkit is positive (though no official stance yet):
https://github.com/WebKit/standards-positions/issues/339#iss...
This is not auto-translation.
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.
On this topic, I have to recommend Hush! It is an excellent free, open-source and well-maintained app for iOS.
When Amazon allows any of the millions of ephemeral clone-storefronts to sell shady or illegal stuff, would you rather have the authorities spend years chasing ghosts or have Amazon change their rules to make sure such illegality and abuse aren't possible in their marketplace?
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…"
I guess it depends on what you read into it.
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.One thing that strikes me reading this, is that the only thing that's changed is that Google won't disallow it. But I think it would make more sense if the ICO actually just went after the companies doing fingerprinting directly, instead of being angry at Google for not enforcing things for them.
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.
Another interesting Rust-based Javascript bundler is Oxid / OXC.
- https://github.com/oxc-project/oxc
It's also what Rolldown (https://rolldown.rs/about) is basing their in-development bundler on.
I see it in the readme now, interesting!
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-...
I've started using Mise for some stuff at work. Haven't digged in a lot yet, but looks really promising.
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.
Not sure if this works with artifacts pushed to GHCR (Github Container Registry), for example Docker containers. I think not.
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.Great, thanks!
I made a mistake in my comments above:
I meant to write "Would be neat if the *Linear* integration had configurable fields (at the team level set which ones are visible, and set fixed values for some of them). For example, I don't want anyone to set the project (that's the triage step in Linear), and I want only some teams to be selectable, I'd like to skip the 'effort' altogether, etc."
Some thoughts:
- Make the scrubbed headers configurable (if it isn't already). For example, our token header is called `X-Session-Token` and is passed on every request. Would your current regex scrub this?
- Maybe clarify that the seat (pricing) is for recorders, not for people viewing them (which I think is a reasonable choice).
- Would be nice to configure auto-deletion of Jams after X days. We'd probably go with 180 days.
- Would be neat if the Sentry integration had configurable fields (at the team level set which ones are visible, and set fixed values for some of them). For example, I don't want anyone to set the project (that's the triage step in Linear), and I want only some teams to be selectable, I'd like to skip the 'effort' altogether, etc.
- Make it possible to configure the text body of the Linear issue, with placeholders for content. For example, we'd like to skip the full-screen (non-cropped), maybe show window size or add other metadata that is often relevant to us.
One question:
- For integration with Linear, you are asking for write access to the workspace. Maybe explain why that's needed, and what it means? Same for read (though this seems more reasonable, an explanation would still be useful)
Key features mentioned in the release notes are:
- Bloom filters for queries ('needle in haystack' problem)
- Native OpenTelemetry support
- Updated helm charts
- Lambda/Promtail support dropping labels
- Docs improvements
Personally, I'm thrilled that the problem with high-cardinality labels will [hopefully] get addressed after 6 years (that's the top item, with bloom filters).The architecture Loki has chosen is great for keeping costs down and using simple blob-storage (S3) for data. However, it makes it hard to quickly query unique keys such as trace IDs or user IDs. But bloom filters will hopefully will do the job.
I raised the needle in haystack problem back in 2018, so it's great to see this landing:
https://github.com/grafana/loki/issues/91
For anyone that's curious, bloom filters is a clever technique:
Yeah, but gaining trust with benign patchset would be the first step.
The goal is to use a standardized test framework to ease writing of tests in XZ.
Much of the functionality remains untested, so it will be helpful for long term project stability to have more tests
-- Jia, 2022-06-17
This was a long time in the making.I think the liberal immigration policy might play a role here. Sweden has taken a huge amount in the past 15 years, twenty percent of the population are immigrants.
Obviously, most of them are not criminals. But on a group level, they are more likely to commit crimes. About 2x compared to Swedes, after adjusting for income, age and education (it's higher before adjusting, obviously).
Digging deeper, there are large differences between groups.
For example, the group men (compared to women) are much more likely to commit crimes. Another factor that stands out is geography. People from East Asia have similar crime-rates as Swedes, while people from Africa are 5-10x as likely to commit crimes (compared to Swedes).
This holds for most categories, including violent crimes, sexual crimes and a bunch of other groups.
Here is the landing page from the Swedish National Council for Crime Prevention, a governmental agency:
https://bra.se/publikationer/arkiv/publikationer/2021-08-25-...
Here is the report with the data mentioned above:
https://bra.se/download/18.1f8c9903175f8b2aa70f6df/163110731...
JPEG XL is awesome!
One thing I think would help with its adoption, is if they would work with e.g. the libvips team to better implement it.
For example, streaming encoder and streaming decoder would be the preferred integration method in libvips.
Neat library!
We're using randomly generated strings for many things. IDs, password recovery tokens, etc. We've generated millions of them in our system, for various use-cases. Hundreds of thousands of people see them every day.
I've never heard any complaints about a random content-id being "lR8vDick4r" (dick) or whatever.
But nowadays our society is so afraid of offending anyone, that profanity filters has extended all the way to database IDs and password recovery tokens.
(there are some legit cases, like randomly generated IDs for user profiles shared in public URLs, that users have to live with, but even there just make the min length 8 and you're unlikely to have any full-word profanity as the complete ID; put differently, I don't understand why they made the block list an opt-out thing)
Based on the comments, there are obviously many people who have had bad experiences of this.
I agree with the general sentiment, I think this is a common behavior in many organisations.
But at least anecdotally, I'd just like to mention it's not always true.
For example, a friend who had loyally had worked at the same company for several years. He was going through some tough times personally (family) and was basically not doing anything useful for half a year or more.
Since he had been there for a while, they knew him well and didn't try to force him to get more things done, or anything else. They were basically fine with him doing nothing for many months. About half a year later, things were looking better for him on the personal front, and he would be back to speed (mostly).
If he hadn't worked there for several years [been loyal], I doubt they would have treated it the same.
Hello 20 ft. and 13 lbs, great if you could use the metric system to describe your aircraft :)
Also, in engineering it's pretty common to use it these days, even in the US.
Any plans for a pay-as-you-go (self-service) plan?
I emailed you and asked you to take my money, but your sales team disqualified us because we wasn't big enough (reasonable, sales people are expensive).
But I think many smaller firms would like to pay a fair price for it, and have more configurability (logo removal, etc).
Another option in this space is https://netbird.io/
Unfortunately they still don't have an iOS client (which e.g. Tailscale and ZeroTier has).