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).
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).
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.
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)
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).
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)
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.
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?
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)
'''
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...