jka

Quoting from a relevant wikipedia entry[1] to hopefully pre-emptively reduce some confusion:

'''

In parliamentary procedure, the verb to table has the opposite meaning in the United States to the rest of the world:

- In the United States, to "table" usually means to postpone or suspend consideration of a pending motion.

- In the rest of the English-speaking world, to "table" means to begin consideration (or reconsideration) of a proposal.

'''

[1] - https://en.wikipedia.org/wiki/Table_(parliamentary_procedure...

It's a shame that (if I remember correctly from the video?) the bug that allows this is restricted to single-player; if not, I suppose it'd be possible to start the "outer" map as a network game, and then use the second instance of the game to join the outer instance over the network (including the possibility to walk around and find the original player character).

There can be a good intellectual challenge in refactoring code like that to be both efficient and readable (although at some extremes, and depending on the programming language, perhaps there'll be conflict between those two goals).

All the better if that refactoring is in a FOSS application/library to save other people the repeat effort (and potentially gather further improvements).

Your question reminded me of Raymond Hettinger's excellent 2015 PyCon talk about refactoring functional-but-messy Python code: https://www.youtube.com/watch?v=wf-BqAjZb8M

(as previously discussed on HN: https://news.ycombinator.com/item?id=10023818)

Per-employee distribution might tell one story; per-manager distribution might tell another.

Offering an opinion: the tech industry is invested in the success of PyPI -- perhaps not always in a literal monetary sense, you're right, but certainly in an ecosystem sense.

Ok: you've provided two requirements that I agree with:

- It should be possible to compare between two releases (I'd personally like to see a code diff, ideally with a complete path of the commits involved)

- Providing a reputation visibility mechanism (for publishers? author(s)?) across a series of releases is important

Those don't require user accounts necessarily, though. And responding to the end of your message: identity assurances, yep, those seem necessary; access management, I'm not so sure.

Odd but serious question: could there be ways to distribute versioned software that doesn't require management of developer accounts (and the associated time-and-effort costs related to account takeovers)?

That's a very good point regarding operational cost of handling account takeovers.

I'm not sure I have much useful commentary to add, but it does occur to me that a sufficiently-sized pool of software users could inspect changes (either at individual-commit-time and/or at tagged-release-time) regardless of whether each changeset is by the same author or in fact a different person every time.

Choosing to use FOSS software to build products/services has always involved an element of caveat emptor, and even with the best of intentions, mistakes and errors are introduced sometimes, as they can be into any commercial software.

The technology industry (as the typical consumer of FOSS) generally understands that and introduces appropriate measures (dependency reviews, hiring developers with relevant experience, requesting professional security audits, keeping backups, ...).

Despite all those (sometimes expensive) measures, industry continues to develop (and indeed thrive) using FOSS, implying the trade-off is worthwhile. My guess is that it is in fact massively worthwhile, especially when comparing the technology economics of today with years and decades past.

Therefore I think it's reasonable to ask questions any time that barriers are raised -- however small -- on the production-side of FOSS. That's not where the bulk of the revenues are accruing.

(I also have a vague sense that 2FA could later be misused as an attempt to strongly-attribute blame, which again feels potentially unfair/unbalanced. if your business risk is high when upgrading packages, then you should review those updates more carefully and keep a record of the financial efforts and rewards)

Trying to ignore any hype, lofty sci-fi ideas, or potential philosophical questions for a moment: roughly speaking, it sounds like this is a search engine, for use in a neat and thought-provoking use case.

There's an architecture diagram[1] alongside the source code, and my summary would be:

- The system has in-house web indexes built from Common Crawl[2] data

- The system receives snippets of text from Wikipedia and determines whether existing citations exist and whether they are valid

- If no valid citation exists, then the system performs queries against the indexes to find relevant URLs

It'd be interesting to learn how this approach fares compared to pasting the relevant paragraphs of text into search engines and excluding site:wikipedia.org from the results.

Something about feedback loops and data quality makes me wary that too much application of automated systems like this would lead to a degradation of content quality (each updated copy an imperfect translation or reference to an existing one).

[1] - https://github.com/facebookresearch/side/tree/a595fb09c85233...

[2] - https://commoncrawl.org/

Related to this, there's a really good talk by the founder of lichess that includes an overview of the cheating problem, and the techniques they use to detect and manage it.

The relevant section of the video on YouTube is: https://www.youtube.com/watch?v=LZgyVadkgmI&t=1080s

I think I'd prefer a code review discussion where the file being modified is a CSV file listing everyone in the organization's roles, seniority levels, and compensation, and where anyone in the company (and perhaps at a later date, outsiders) can comment on and view the discussion and file history -- both while the promotion review is in progress and after the fact.

(perhaps the inputs to the promotion suggestion could be from a documented and equally-open algorithm; I still think it'd be nice to have the results reviewed and discussed (openly, by humans) before they take effect so that potential unfairness -- either in the levelling, or in the algorithm -- could be addressed)

(see also 'Sam Vimes "Boots" theory of socioeconomic unfairness': https://en.wikipedia.org/wiki/Boots_theory )

It's generally not a model that has much supportive mindshare for the web currently, but it is possible to achieve tamper-prevention without requiring the content of communications to be encrypted.

For example, most official Debian[1] and Ubuntu[2] package repositories currently use HTTP (not HTTPS) by default for content retrieval.

That's reliable thanks to public-key encryption; the packages are signed, and the receiver verifies the signature.

Someone able to inspect your network traffic could, for example, tell that you've downloaded a genuine copy of "cowsay". Or they could detect that the server replied with a tampered copy (something that your client should reject as invalid).

[1] - https://wiki.debian.org/SourcesList#Example_sources.list

[2] - https://ubuntu.com/server/docs/package-management

Digital experience ('DEX') issues reported by employees, from the original report:

- 37% : Security/regulatory policies

- 37% : IT overwhelmed by number of issues that need resolving

- 35% : Lack of training for IT personnel

- 34% : Handling the shift to hybrid/remote work

- 32% : Increasing number of endpoints to manage

- 31% : Technology in place is not appropriate for supporting DEX

- 27% : Lack of knowledge around DEX

- 25% : Lack of budget to support DEX efforts

- 19% : Lack of buy-in from leadership around importance of DEX

- 2% : No challenges being faced

(with some snark: statistics on signup/login requirements before viewing published reports, and presenting statistics in images instead of tabular data formats were not reported)

Worth mentioning that the experimental payments during this research were one-time-only.

(a few descriptions[1][2][3] of Universal Basic Income seem to define it as including recurring/periodic payments)

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

[2] - https://basicincome.stanford.edu/uploads/Umbrella%20Review%2...

[3] - https://www.investopedia.com/terms/b/basic-income.asp

Often I begin from the assumption that the marketplace -- for some reason -- wants to gather as much information about customers as possible, rather than to sell them minimal products that meet their requirements, and so:

- Unless you're careful, searching around may lead you to multiple, spammy-looking websites and domains that appear designed to gather your purchase intent and search information, to share/sell and affect your decision-making

- The products that you find may include surplus functionality (be that hardware, software, subscriptions, tracking, account login requirements, ...) that aren't genuinely required for the requirements that you have

- Since vendors want to build social influence around their products (again, to affect your purchase decision-making and that of your peers), they'll potentially provide rewards, discounts, talking points, and other perks to highly-networked individuals as long as those people remain brand-loyal

- Since continued revenue is an incentive for many vendors, they'll reinvent products on a regular basis and/or use planned obsolescence to encourage you to spend more than once for essentially the same functionality. That could be accompanied by marketing/social-influence campaigns to subtly (or not so subtly) discredit previously-acceptable products (especially if those continue to meet requirements). I can see there being public-good reasons for migration away from problematic products of the past; however I'm not convinced that they're commonly the reason these upgrade cycles are suggested

- If competing products emerge that may meet requirements and are seeing high adoption rates, there is a possibility that vendors will acquire ownership of the competing product outright (stifling competition, although also perversely creating incentives for new-entrant companies to create apparent-competitors that are largely intended to be flipped to a larger incumbent rather than to distribute a lasting higher-quality solution)

- Similarly, if competing products/technologies exist, then vendors may encourage the promotion of brand names that obscure (duplicate, or are similar to) the name of the competitor, causing various forms of confusion and dividing would-be adopters (and their opinions) between the vendor's brand and the competitor's brand

It's possible that I've misinterpreted and misunderstood some behaviours of industry here - based on those, you could be excused for thinking that the goal of these vendors is to extract as much revenue as possible from people as opposed to providing lasting, effective and sustainable products.

By the sounds of it, I think what you want is something like a robust, reliable solid-state music player, as commonly available at low-cost over a decade ago.

The Wirecutter - generally a trustworthy resource - has a section on audio equipment[1], although they don't mention any portable personal music players, as far as I can tell (possibly because many people use their smartphones for this purpose, nowadays).

Rockbox[2] (not to be confused with a similarly-named line of music players) is an open source firmware project that can run on a range of devices[3], many of which may meet most of your requirements.

However, unfortunately it does not appear to have widespread bluetooth support currently. There is work-in-progress[4] on that (last updated in 2020), but one of the challenges with free-and-open-source software is that timescales are difficult to predict, and adding demand/pressure for functionality and bugfixes doesn't always help, so it's hard to tell if-and-when that may be available.

The website gh.de (mentioned in the HN thread that you link to) has a fairly good price-comparison section[5] for portable music players with many relevant filters.

In general: I try to wait until a product that meets requirements arrives (although this often means being well-behind-the-curve compared with peers), try to use the existing devices I have for as long as possible (and extend and enhance their functionality, an area where FOSS can be very helpful), and when possible, purchase products from vendors that have practices aligned with openness, minimalism, high-quality, sustainability and durability. It's difficult! And it leads to frustration after some purchases when realizing that they aren't up to expectations. But that's part of the learning process, too. Good luck.

[1] - https://www.nytimes.com/wirecutter/electronics/audio/

[2] - https://www.rockbox.org/

[3] - https://www.rockbox.org/wiki/TargetStatus

[4] - https://gerrit.rockbox.org/r/c/rockbox/+/3044

[5] - https://geizhals.de/?cat=mmp

Slightly-curious, slightly-unnerved, slightly-paranoid question here:

Is there any chance that this code snippet was sampled from repositories that contained associated commentary/discussion, guiding GPT-3 to produce similar explanations?

Or is this genuinely an explanation that it can produce without context local to the code in question?

And what number of people are able to determine the answer to my first question?

Roughly speaking, yep - Common Crawl provides a sizable chunk of web data (420 TiB uncompressed, over 3 billion unique URLs, as of May 2022; historic statistics here[1]), and is updated on monthly basis. Not near-real-time, true, albeit relatively fresh.

A question to ask could be: how often do users care about information from a few minutes ago, compared to information that has been available for a longer duration of time?

[1] - https://commoncrawl.github.io/cc-crawl-statistics/

A correction/clarification since writing the parent comment: publication of packages requires an authentication token, and does not require an interactive 2FA challenge. Generating a suitable token for package publication, however, does.

(that implies that a naive implementation of '--2fa-signed-packages-only' flag would mean 'packages that were published using tokens that were generated by a 2FA-authenticated user; possibly a subtle distinction, but maybe worth mentioning)

Hrm, fair point. Although migrating 'backwards-compatibly' like that could leave a lot of people in the cold if-and-when a security update for the package is released (and we're talking about critical packages here, at least for now).

Sure, accepted. That'd be a disruptive change, though, and I think that a better approach is possible.

The suggestion regarding separation of (immutable) packages and policy in the article could provide some hints in that direction.

> You can always publish your creation on your website or wherever.

What you're suggesting wouldn't solve the problem for critical packages, though; the effect would be similar to yesterday's package unpublish issue[1] (all users of the package would have to update their dependency references despite no change in the content of the code).

[1] - https://news.ycombinator.com/item?id=32026624

It seemed clearly-written and thought-provoking to me; the author doesn't claim that 2FA is a burden, either.

Writing and distributing software should be straightforward so that everyone can participate. And consuming software should be safe so that people and infrastructure are protected. Finding a security model that achieves both should be the goal.

PyPi appear to have walked a reasonable line on this so far, and it's worth considering and discussing what the future could be like.

In particular, if package indexes start introducing additional requirements for developers, as mentioned in the article, then I do worry that it could risk moving an unreasonable level of burden onto developers (who may initiate or develop code purely for their own enjoyment).

Currently the "critical package" categorization may offset most of the likelihood of that occurring, although I'd expect there could be problems for some projects even so.

I wonder whether PyPi considered making 2FA-at-publish-time optional and instead offering a question of 2FA-at-package-install-time.

In other words: "pip install --2fa-signed-packages-only" or similar.

It's possible they didn't, or weren't able to, because the ecosystem is already widely deployed and many package version upgrades (including transitive dependencies) occur automatically.

Roughly speaking: I like the author's suggestion (quoted below) of making the the software package ecosystem an immutable (content-addressed?) space, where policies and attestation about whether to use those packages is opt-in based on rules-based overlays. That'd be ambitious but technically feasible, I think.

"So if I were to wish for something, then that the index has no policies beyond immutability of assets, and instead we use an independent layer of the index to enforce policies."

Thanks for the response!

> if I'd go to my office colleagues and tell them to run some commands in the shell, they'd think I'm mad.

Depends on the colleagues, potentially - I often feel like I underestimate what other people are capable of learning, and that the resulting conversations can seem unintentionally condescending as a result of that (i.e. not preparing and demonstrating what's possible for fear that someone may not understand).

> The user interface has to be super slick everywhere because an average user is very spoilt.

Yep, that makes sense. However, whether I'm an employee, a business owner, an investor, or a partner who wants to see a business succeed: if I learn that the company is spending on software when there are lower-cost alternatives available that are ignored largely due to look-and-feel concerns.. some cognitive dissonance may develop. Especially if the potential cost savings could be pooled with others towards resolving those issues.

(on a potentially more practical note: what I hear from you is that user experience frustration can lead to dissatisfaction with software; I'm not sure what the best routes forward there are, other than encouraging further feedback and finding ways to improve and promote product design in user-facing FOSS)

Can you share one or two aspects of FOSS office software that caused problems for you?

(from my perspective, it's a modern miracle to be able to run "apt-get install libreoffice" at a command-line and have freely-available, no-license required office software available within a few moments including nearly like-for-like functionality and file-format compatibility with other office suites)

> Trademark violation should be enough for the moderation team I would assume, for most of the junk apps.

For clear trademark infringement or license violations, sure.

However, it'd be permissible, as I understand it, to build re-label-ware (not necessarily malware, but simply low-effort software built using FOSS foundations) using MIT/Apache and other permissively-licensed software and to publish that on app stores with price tags attached.

I have to admit: I'm not familiar with the types of apps that the policy intends to handle in practice -- but re-label-ware would seem like a rational opportunity for developers to pursue in a payment-enabled marketplace without rules to prevent them.

> The only way to solve this really is proper vetting of each app before it is accepted on the app store

That sentiment doesn't sit right with me somehow. Computers can run software, and attempting to gatekeep that process (in an evolving and culturally-diverse world) seems like a path fraught with problems.

Having transparency about what software is intended to do - and perhaps system-perimeter observability that helps users (and, with their knowledge, their friends and colleagues?) to monitor what it has really been doing (to inspect whether that matches their expectations) seems like a potential space for opportunity.

I'm hypothesizing here, but it's possible that the policy was introduced so that the teams who work on moderation of apps (including the open-source-derived junk/spam ones) have a documented policy that they can use when justifying each removal - removals that are likely based on user-based flagging of problems.

If that's the case, Krita would probably remain listed; it's unlikely to be reported as spam and is genuinely useful software, so the moderation team are unlikely to consider (letalone apply) this policy in relation to it.

That said, the policy is clearly not worded ideally if it puts a valid, legitimate app into violation. So it's good that the SF Conservancy are raising a concern about this (which it seems like the Krita developers have read[1], incidentally).

The metaproblem seems to be that we want people to install "the good, safe software" and not "the bad, harmful software" -- and especially not to pay for and incentivize creation of the latter.

Is that best achieved using moderation and written policies after-the-fact? Does the presence of absence of paid apps and in-app payments affect the alignment of incentives? Is there eventual, informed and communicated consensus from users about the best and safest apps to use?

I feel like we may be trapped in a local minima at the moment where a bunch of conditions around app stores are non-ideal.

[1] - https://twitter.com/Krita_Painting/status/154524168859936768...

I agree with you, although perhaps for slightly different reasons:

As of 2022, within the vicinity of almost any mechanical watch, there are likely to be tens or perhaps hundreds of inexpensive satellite-based location-estimation devices (GNSS) - inside smartphones, vehicles, internet-of-things devices, etc. There are also purely radio-based clock signals.

Those receivers, which are usually entirely passive (receive-only) measure accurate time signals as a component of their functionality.

It's important (and useful!) to track time accurately, and there's certainly nostalgia/envy aplenty to be had in the notion that our ancestors (who may have grown up in an era prior to GNSS) express their devotion through the symbolic hand-me-down of mechanical watches, but... perhaps it's sensible not to be pressured by the hype and -- nowadays -- irrational financial cost (of which, despite the ostensibly factual nature, I think this article is part).

I guess a less trite and more actionable way to state this would be: consider saving yourself the economic cost of a mechanical watch (first-hand or second-hand), and instead spend literal time with the person you love and intended to provide it to - potentially using the amount saved to help fund and remember the moment.

Similarly: if that person would have preferred an expensive timepiece to actual time spent with you, then.. I suppose it's a good deal either way?