aeorgnoieang

I'm guessing you're thinking about discoverablity? I think the comment to which you were replying was pointing out that you might want to serve different images out of different buckets (e.g. because they have different audiences) or use a different bucket for images versus other content.

But if you're happy with just using whatever S3 bucket you have, then there's no reason to switch.

> that's the owner of said service problem

Thus, at least indirectly, it's a potential problem for every user or customer of said owner's service.

Wikipedia and archive.org are supported by donations. That is possible for an image hosting site/service.

"blogs, mailing lists, usenet, IRC" are all paid by someone and all tho their are free hosts for them (or similar services), a lot of people are perfectly fine paying for them and otherwise seem mostly content "to participate in or contribute to surveillance". I'm fine with that too.

But it's very much always been "the way the Internet used to be" to pay for things you value sufficiently. Someone has always paid for everything and gift economies are inherently limited. They're also much harder now than when the Internet was younger.

Academia also seems like a poor example of 'the gift economy spirit'. They're struggling to live up to that spirit badly enough that it's disingenuous to suggest it as something to emulate.

They're still struggling to give away stuff that they've (somewhat implicitly) promised to give away, like their research.

I think a lot of site re-designs are make work for designers. I'm of two minds about it tho. I almost always personally hate re-designs; they're almost entirely extraneous for me. But what else are full-time designers going to do?

> Why do I care about how a site keeps records of payments?

I think you might want to care because that's a basic requirement of any legal business (or non-profit) pretty much anywhere.

The service is also time-limited. Would you pay some amount for images to be hosted for a limited time? That seems like a perfectly valid decision.

It may not be feasible to accept anonymous payments or accept credit card payments without at least an email address.

Also, services like this must necessarily 'bundle' their specific products, e.g. hosting individual images in the case of this site. The transaction costs, e.g. credit card payment processing fees, preclude charging too small amounts.

Maybe it would be possible to avoid requiring an email address, but then I'd expect they'd have to use your credit card 'fingerprint' as an account/user identifier. But I'm skeptical that any credit card processors would allow that, especially given the possibility (and likelihood) that people will upload illegal images like child pornography.

I think the grandparent comment was asking if you'd disable credit card payments for everyone, i.e. for your entire site.

I think it looks perfectly fine. I prefer simple 'lean' designs anyways tho.

Aren't you being insufficiently paranoid? No one should trust their municipal water authority but they can totally trust the makers of water testing kits? Obviously, everyone should reinvent all of the relevant chemistry and biology and manufacture their own water treatment infrastructure. [This is sarcasm. Your municipal water authority is probably fine. Everything involves tradeoffs.]

Huh? They have to know where the scooters and bikes are so they can be collected to be recharged.

> I also switched to Zsh ...

Wait, how hard is it going to be to keep running Bash?

I find planned obsolescence to be fascinating. First-order, it seems obviously terrible, both of the companies that (deliberately) practice it and for their hapless customers.

But second-order (and beyond), particularly from the perspective of the companies, I'm less sure what's best, or if there even is a global, objective 'best'.

Consider the most radically distant point you can imagine in 'self-supporting human group' configuration space, that's still capable of making something like a MacBook. What does it look like? How is funded/financed/supported? Is it temporary, i.e. more like a one-time project like making a movie or a video game? Or is it, somehow, a 'going concern'?

The 'going concern' attribute is one that I think is perhaps under-appreciated. One thing that companies, and other long-lived organizations, do well is in organizing people with specific expertise long-term. Think about making a computer, or a washer, or any physical product. Surely the people that make those things, that have done so for an extended period, have a huge amount of detailed knowledge, and wisdom, pertaining to making the specific things they make. What would be lost by them NOT having made the same things for so long? What would our computers, or washers, or pencils, be like if they were all produced by something more like a Kickstarter project?

Imagine another possible world where the 2013 MacBooks were just as good as in our world, but also intended to last indefinitely, perhaps more easily repairable, or made of more common or standard components somehow. Say they lasted 30 years, easily, before needing to be replaced. How is Apple different in this other world? How do they retain engineers like they do now? How do Apple's competitors do this? And, maybe most importantly, how much do MacBooks cost in this other world?

That's very true but still, in my experience anyways, it's much easier (i.e. perceived as 'less risky') to buy SAP and attempt to roll it out than to convince others that custom software would be better.

'Custom' is scary in a way that 'customizable' isn't.

I hope so!

All the "Freedom Markets zealots" I follow are cognizant of everything you mentioned.

I'm sure it'll show up on your shores soon enough.

I've seen proposals along these lines made many times. SE (the company) apparently isn't interested in that tho.

> NLEs

Non-linear editing systems?

The problem isn't earmarking funds in general. Money has to be allocated somehow and it's good to do so explicitly.

The problem is earmarking or allocating a variable set of revenue as funding for something unrelated, and in particular something unrelated that's otherwise valuable or important.

And NOT earmarking or allocating 'sin taxes' to pay for the supposed costs of those sins, borne by the public in the form of the government, seems pretty stupid (to me) if it's actually necessary or desirable for the government to 'manage' those sins or those sin's consequences.

Yes! This is a point I raise frequently. My go-to example is cigarette taxes being used to fund public schools. They should be used to cover costs (borne by the relevant government) of people smoking cigarettes! Otherwise, as has happened, school funding can be hurt by people smoking less, which is not a good situation to have created.

The degree by which governments routinely violate the accounting principle of matching revenues to expenses is awful.

No, [2] is incorrect – exactly opposite. The included code was 'guaranteed to' (and did) work under the default OS configuration.

> Google should request from and/or work with Apple here, not hack around them

Or Apple should implement all of those features and reach out to and work with Google so they don't have to hack around anything.

I wouldn't be surprised if Everest specifically has some coverage nowadays.

Well, yes, and un-ironically – during the development of a new airplane or bridge design.

You'd obviously want a new, experimental, or prototypical design to fail ASAP so you can fix whatever the problem(s) are sooner than later.

I'm pretty sure most bridge or airplane failures are either due to mistakes made during building or, probably even more often, failing to maintain (and monitor) its condition.

But the whole point of agile is to make, and release, smaller sets of changes at a time precisely so those changes can then be tested or validated more quickly than otherwise. That may – probably is – more difficult with airplanes and bridges versus software so the relevant tradeoffs are different, but the basic point about minimizing the duration of making changes so those changes can be tested sooner seems equally applicable.

Let's think about bridges. I'm sure most bridges use a standard design with standard materials – that part then has already been tested and validated. But even at the stage of evaluating a standard bridge design and whether and how it could be built in a specific location, I'd imagine an 'agile' methodology would be better than a 'waterfall' one in terms of testing or validating a tentative plan, i.e. you'd want to address the highest priority risks first, and 'fail fast'. You wouldn't want to create a final proposal if you knew up-front that there was no way to anchor a bridge of a certain design in the designated location.

> This was how the MAX part of the 737 MAX was designed. Using a short iteration on top of an existing design.

A lot of software (that's often written about) can be tested 'in production' with fairly minor consequences in the event of 'failures'. That's an obvious difference between developing or maintaining software versus something like airplanes.

But testing or validating the changes made in short iterations is important regardless. Agile stresses the utility of short iterations precisely so the changes in each iteration can be tested and validated ASAP. Whereas in a waterfall methodology, a larger set of changes, i.e. changes that would in agile be split among a number of iterations, is tested or validated together. And the more changes that end up being tested together, the larger the risk is that those changes, and more of them, will need to be scrapped or redone.

The problem with the "MAX" changes of the 737 MAX seems more due to those changes not being tested or validated with the relevant users, i.e. pilots, at all before being 'released'.

Yes, the flawed (or incorrect) reasoning was that the changes were relatively minor and thus didn't warrant the regulatory requirements for 'significant' changes. But that doesn't seem to have anything to do with how the changes were developed, whether their methodology was agile or waterfall (or anywhere in between).

Obviously you're more likely 'to have a bad time' if you don't respond to, let alone seek, feedback from users about the changes you're making.

Of course "anecdotal experiences" are evidence. Yes, they're messy, and may not be applicable to other circumstances, but they're certainly informative.

I'm pretty sure airplanes and bridges aren't designed using 'waterfall'. I'm sure they're built, i.e. 'deployed', using a well-defined process. But, ideally, the well-defined process by which they're built should itself probably be designed or developed with 'short' iterations.

In my mind, and agile approach would involve a series of 'tiny' incremental migrations from the existing system to the new one. I'd actually expect that to work much better than attempting to switch over everyone all at once, after years of development. That either doesn't work or works very badly in my experience.

I think agile could work just fine even for airplanes and bridges, and I imagine people are already doing it.

Building the actual bridge on which people will expect to drive or walk or whatever is probably better thought of as deploying a bridge (design), even if it inevitably also includes some ad-hoc on-the-spot development too.

But when developing a new bridge design, it seems extremely valuable to be able to iterate as quickly as possible.

Doesn't infrastructure have users too? Why wouldn't 'user story' mean something to them?

All else equal, smaller or shorter feedback loops are better. And often shortening a feedback loop is worth considerable tradeoffs elsewhere.

It's certainly the case that being able to iterate fast may not be currently possible, but being able to do so, or even just being able to iterate faster should probably always be a priority (even if not the top one).

This all applies even to physical real-world infrastructure. I remember a story about a city somewhere (South America?) where the mayor (?) was able to shorten the feedback loop whereby roads were built or repaired. That seems like a good, even great, thing, even at somewhat considerable cost.

What kind of big infrastructure projects were you thinking of specifically?

Pick one framework – any is fine – and finish the (or a) minimal version of a basic simple app.

I'd suggest minimizing, or even ignoring, JavaScript. A really basic CRUD app doesn't need any.