jka

(I don't necessarily see anything unethical or problematic - except perhaps that it seems surprising - in the sense of a lack of transparency - that the company doesn't list (or even mention?) the pornography industry on their own website. if they have no qualms doing business with companies in that industry -- which is an understandable stance for them to take -- and if it's a significant source of their revenue -- then perhaps their transparency principles should override their marketing and dealmaking strategies so that their potential customers and the public are provided with a more honest description of the company)

Although their homepage doesn't really mention it much, I expect that Yoti (the partner company providing age and identity verification) does most of their business with online pornography sites including PornHub that accept user-uploaded content.

Their business is looking to expand into providing age assurance for the under-13 age group, according to their latest "Council of Guardians" public meeting notes from Dec 2021: https://www.yoti.com/wp-content/uploads/Guardian_minutes_9_D...

I don't know what to think about any of that. I suppose it's kind of predictable that a business like this will appear and provide these services given that so many people have smartphones nowadays.

Do you know what routing provider(s) were in use, out of interest?

It looks like the app builds upon[1] the kpublictransport library, which should offer a few options[2]. I'm not sure how the selection of those is surfaced in the app though, not having used it myself.

[1] - https://invent.kde.org/utilities/ktrip/-/blob/1bd4e070143eb0...

[2] - https://github.com/KDE/kpublictransport#backends

An important observation in this video (also noted by the oxide.computer team while they were building their foundations, if I remember correctly):

What you think of as "your computing device" (laptop / phone / etc) is increasingly in fact a network of computers; there are multiple processors in there, running a variety of firmware and software.

The implications of that could be a bit complex and mind-boggling. Arguably it's a situation somewhat similar to internet-of-things, or something more Kubernetes-like? You're no longer managing a single von-Neumann machine, you have a small fleet of computing hardware with differing roles, abilities and responsibilities. How do you make a system like that straightforward to manage and observe?

(as usual, perhaps I'm over-generalizing the problem: if there are only a few items of firmware within each system, perhaps no such abstraction layer is required)

Around April 2020 I identified a project need for an "inverted search engine" - a system that would accept documents (recipe ingredient lines, like "three large onions") as input, and would match those against a dataset of terms (ingredient names, like "tofu" or "tomato").

That would have been possible with a feature like percolation[1] in Elasticsearch, but I felt that the overhead of maintaining state (percolator queries) by using a network service would be excessive and that building an in-process alternative would be feasible.

The result is hashedixsearch[2], a pure-Python search engine library with support for stemming, synonyms and a few other features[3] to support the use-case.

It builds upon inverted index support provided by the hashedindex[4] library.

[1] - https://www.elastic.co/guide/en/elasticsearch/reference/curr...

[2] - https://pypi.org/project/hashedixsearch/

[3] - https://github.com/openculinary/hashedixsearch/blob/6980ee63...

[4] - https://github.com/michaelaquilina/hashedindex/

Ech, forgot the link, and now can't delete this post.

It is: https://recipesage.com/

I'm probably drawing parallels here that someone who has a better understanding of the academic world could validate or reject, but.. it feels a bit like there are more similarities emerging between published research and published software.

Citations are somewhat similar to dependencies, and post-publication review (as mentioned by the tweet's author) could be seen as similar to code review.

(note: when I say "more" similarities emerging, that's because I think there's already a positive trend towards publishing code and datasets alongside research papers, aiding reproducible results)

Strange; what I get from those articles is roughly:

- Google tailors results to users, so it shouldn't be considered a common carrier

- Google doesn't charge users for access, so it shouldn't be considered a common carrier

- Internet search isn't a vital public service, so Google shouldn't be considered a common carrier

I totally believe you that there may be reasons not to consider common carrier a magic solution, but... I disagree with all three of those points.

(in other words: I think two people searching for the same terms at the same time should see the same results, and I don't think it matters that the service is funded based on indirect (advertising / tax) revenue, and I do think that many people -- in all kinds of environments -- can reasonably expect Internet access and web search to the point where we should consider it a public necessity)

Anyone feel like ratcheting up the optimism in the room for a change and trying to make this happen? (upvote, share with your network operator friends, ISP friends, mention it at relevant meetups, and so on)

Yes, maybe it's a slightly ridiculous site, but I doubt you'll regret being involved if you do promote the switch to IPv6 and it becomes feasible as a result of that.

For anyone curious about potential open-source migration options given the prospect of uncertainty around VMware pricing and support:

- xcp-ng[1] is a support-available fork of XenServer. Migration[2] can be performed using export to OVA format and subsequent import into the built-in Xen-Orchestra interface.

- proxmox-ve[3] provides a management UI for Linux Virtual Machine (LVM) and Linux Containers (LXC) hosts and provides various vendor migration guides[4]. Both commercial and community support[5] is available.

- The Xen Hypervisor[6] is capable of hosting x86 and ARM virtual hosts, and their project provides a VMware migration guide[7]

[1] - https://xcp-ng.com/

[2] - https://xcp-ng.org/docs/migratetoxcpng.html#from-vmware

[3] - https://www.proxmox.com/en/proxmox-ve

[4] - https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox...

[5] - https://www.proxmox.com/en/proxmox-ve/support

[6] - https://xenproject.org/developers/teams/xen-hypervisor/

[7] - https://wiki.xenproject.org/wiki/Migration_from_VMware

See also: Pew's in-depth 2017 report: https://www.pewresearch.org/social-trends/2017/06/22/america...

Upvoted and agreed, that's a reasonable complaint. Can you provide sources that illustrate the absence of correlation after dividing the dataset?

I haven't yet, although I did find this publication from Boston University positive correlation between increased gun ownership and increased non-stranger homicide rates: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4167105/

As far as I can tell, the 500k-3m figure is from an unpublished[1] report that was commissioned by the CDC - further validation could be helpful.

There is also separate disputation of the figure in a report[2] by Harvard's Injury Control Research Center.

[1] - https://www.washingtonpost.com/news/wonk/wp/2015/01/16/the-s...

[2] - https://www.hsph.harvard.edu/hicrc/firearms-research/gun-thr...

There is a correlation chart[1] of gun ownership and gun deaths per state for 2013 in this article:

https://www.motherjones.com/politics/2015/07/gun-owners-stud...

(correlation does not explain causation, but it may help to guide analysis)

[1] - https://web.archive.org/web/20211204010352/https://www.mothe...

Could you add a reference to some statistics around that?

I found this, although it mostly contradicts your claim (with the exception of gun deaths due to assaults on people in the age range 5-34): https://web.archive.org/web/20180829034947/https://injuryfac...

A theory: the number of firearms (which translates into how accessible they are) isn't a linear scaling factor in the problem.

Comparative population could be relevant, although also doesn't explain the statistics you reference.

To try to prove/disprove the argument: has the prevalence (or nature) of bullying changed?

Supporting dragontamer's claim regarding number of firearms:

According to a report[1] by Small Arms Survey in 2017, there were an estimated 120 civilian firmarms per 100 people in the USA:

https://en.wikipedia.org/wiki/Estimated_number_of_civilian_g...

That's almost twice as many as the next-closest nation.

[1] - https://web.archive.org/web/20180620231909/http://www.smalla...

Nice - perhaps there's some kind of equivalence (or at least similarity) between lenses and those migrations. Thanks for the response!

Eh.. probably because I learned of lenses from Ink & Switch in the first place: https://www.inkandswitch.com/cambria/

Do you have any plans to handle schema changes for the content stored within the CRDTs as the clients evolve?

(I've been puzzling over that question during some local-first dabbling; I have a feeling that lenses[1] -- or something like them -- may provide a route towards schema version upgrades without any peer synchronization guarantees)

[1] - https://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslide...

Sorry, I was unclear: that's what I meant, too.

You would find cookie consent options in your browser settings (for example, near "Privacy Settings"), and you would configure your rules there (with sensible defaults).

You shouldn't see any cookie consent pop-ups while browsing the web, as a result of that -- your browser would communicate your preferences for you.

As I said though: I'm unclear on the status of the ePrivacy Regulation.

Posted after searching around to find existing examples of source-control for low-code platforms (re: discussion at https://news.ycombinator.com/item?id=31508130).

Potential risks:

- Vendor lock-in: if each low-code platform offers a different set of components and workflows, then it may be difficult to move to another if, for example, product cost becomes prohibitive at a later date.

- Dishonest platform: unless the product provides an on-premises option (and many likely won't, partly because it is genuinely easier for users to get started with a cloud option), then both code and data is potentially available for the platform to inspect.

- Business continuity risk: as with the previous risk, this depends on the availability of on-premise hosting (and/or product code available as FOSS run-it-yourself): if the low-code provider ceases to exist, then your business process (or perhaps entire business) may fail.

There are some slightly more technical concerns that I have too:

- Testing and source control don't always seem apparent or well-integrated, making me think that we are going to repeat some of the software engineering mistakes of the past.

- Depending on the concepts and components exposed by low-code platforms, expressivity and capability can be (intentionally or unintentionally) limited. Integrating with an arbitrary weather forecast API that speaks an arbitrary protocol is possible using a generalized programming language - is it equally possible with each low-code platform?

Democratizing technology is important and low-code will I'm certain help discover some excellent workflow improvements.

However I think it is equally important to make it simple for someone to pick up a programming language -- that supports testing, source control, and so on (without requiring the user to know about them, initially...) -- and start on a path that will lead them towards established and recognized best-practices and an open, competitive ecosystem.

The EU's ePrivacy Regulation[1] has (or had - it seems to fluctuate) a goal to move cookie consent into the user's browser settings.

There has (perhaps predictably) been significant lobbying against that by entrenched industry players, so we'll see what emerges as a result.

(I have to admit I'm not up-to-date on the latest happenings regarding this regulation)

[1] - https://en.wikipedia.org/wiki/EPrivacy_Regulation

Unfortunately the arguman.org site appears to be defunct, and the JavaScript from the archived pages doesn't appear to load correctly when using the Internet Archive's Wayback Machine at the moment, but I would refer you to these argument maps:

- https://web.archive.org/web/20210419001046/https://en.arguma...

- https://web.archive.org/web/20210510174650/https://en.arguma...

(if you're really, really dedicated you may be able to use 'view source' to dig into some of the arguments provided, although it could be tricky to get a sense for the tree structure of the debate and the vote weightings)

Definitely going to try tomato rice soon, I hadn't heard of that before. Thanks!

Tagliatelle or spaghetti by default? :)

A relevant quote from the source that the Protocol article is written from:

"Uranium for nuclear fuel is another element of concern. While Russia represents 6% of global production for mined uranium, the country has around 40% of global enrichment capacity. Uranium prices, already high at the end of 2021 due to tightening supplies, climbed by about one-third in March 2022 to the highest level since the Fukushima nuclear accident in 2011 in Japan. While uranium conversion and enrichment plants exist in Canada, China, France, the United States and elsewhere, many of them have been operating at low utilisation rates or are idled due to weak profitability."

It could be worth reading the source article for this; it's written in fairly clear language and includes similar data charts: https://www.iea.org/commentaries/critical-minerals-threaten-...

Promoting clean energy isn't mutually exclusive with reducing consumption (at least in the short-term, until clean energy is both the norm and in surplus).