ary

Personally I blame the irritation and cost of setting up private subnets that can access the Internet via NAT in AWS VPCs in addition to Docker's interactions with UFW. Private VPC subnets with NAT Gateways are both unacceptably costly and complicated to setup (source: recently dealt with the combination of NAT Gateways + the Network Firewall service in AWS). Throw in the need for VPC endpoints for many workloads and AWS networking starts to look like an extortion racket for those who want the majority of their infrastructure to be sequestered from the Internet.

I believe the max duration of an assumed role session is 12 hours, but this can be changed per-role.

I have been in this near exact situation, except that for me it was someone using one of my legit email addresses that isn't (or wasn't) also an Apple ID.

Apple Support was happy to shut down the account for me given that I didn't want access to it, but instead just wanted it disabled so that it couldn't be used. If you're trying to get access to the account Apple is going to be understandably resistant given that even if it was setup in error it may contain sensitive information sync'd from a device.

You can request that they disable the account and make it so that the email address cannot be used to sign up again. Given that this was a random address you may need them make some kind of filter for your domain. Also, given that it sounds like you catch all email that goes to any address for your domain you've basically removed a way to know if addresses are in fact legit since they don't bounce email. That may be why your domain was used for this purpose in the first place.

> I definitely spend many hours each week fine tuning PowerPoint slides, reporting, over communicating, team building, teaching people to communicate differently, etc - which again, seems to make everybody happy and impressed

This is why people love you. You're massively underestimating the amount of spoon-feeding people desire. The alternative to people like you is for individuals to do the work of understanding and empathizing outside their areas of interest or domains of expertise and/or comfort.

This is the absolute antithesis to how I operate and I disagree almost to the point of being offended.

Try working in an environment where team leads are allowed to make up whatever names they want, create as many projects/services as they want, and organize everything based on whim. You get this: https://www.youtube.com/watch?v=y8OnoxKotPQ

For me that is not a parody, it's lived experience.

> I’m probably being overdramatic there, but I hope my point is clear. “Descriptive” names don’t create transparency, they create the illusion of transparency. If you see that something has the name OrderStatusService, you will instinctively assume you know what it is and does, and you will probably be wrong.

When what a thing does changes then the name should also change. I almost want to counter this Medium post by arguing that READMEs should be works of fiction because the project they describe might change over time.

This is a bizarrely emotional response to me. PyPI offered to provide a security key to make the maintainer's life easier so it's hard to see this as an "entitled" act. When I see the core infrastructure for open source software ecosystems improve I cheer that effort on.

While I am in full support of not asking too much of open source maintainers a cooperative stance makes the overall situation better for everyone involved. This could have been handled in a better way.

This is clearly not true. Having a second factor helps maintain security in the situation where your password is compromised (phishing is just one scenario). It isn't perfect, and can itself be defeated. However, compromising an account with 2FA is demonstrably more difficult than one without.

We solved this problem by paying a healthy hourly rate so that candidates don’t feel taken advantage of if we don’t move forward with them.

I should note that this seemed to help offset the concerns of people with families. They definitely don’t see it as a waste of time. It also incentivizes us to be sure we’re serious about the candidate.

I'm reminded of when Jobs got rid of the Icon Garden to discourage nostalgia.

http://clarus.chez-alice.fr/c_applegarden.php

This is a ham-fisted attempt to get attention using controversy, and the arguments are so weak they can't even make me mad.

Computing of any kind (including software development) moves around all the time. Sometimes it's more economical to do something with a bunch of servers over the internet, but less privacy preserving. Then user devices become more capable and it's suddenly possible to do everything you need on device and the platform(s) you're targeting all have enough lowest-common-denominator support to make it feasible. On, and on, and on.

This "article" boils down to a myopic view of the industry that is almost solely supported by the solutions very large development teams have had to come up with to handle their human scaling issues.

The author seems to be completely blind to the underlying issue. Lack of numeracy, much less advanced numeracy, in the general population makes it difficult to communicate about complex topics.

Communication with the general population is key.

You don't "use" it because there isn't demand for its use. The advances we dream about in the sciences are retarded by a widespread lack of understanding regarding how those advances are made, how long they might take, what they cost, and what costs would be offset by their achievement.

If anything needs to change it's the teaching of mathematics primarily as a language to describe everyday life more accurately. The question every grade school child asks, "why do I need this", requires an irrefutable answer that doesn't need several years worth of prerequisite knowledge. Then we need to get on with improving our civilization.

> I always advise people who get exploding offers from companies to just accept them and then back out later if they need to

This is not a sustainable long-term strategy for most people. You know what is? Walking away from the offer immediately when it has an overly-aggressive expiration date and letting them know the reason.

Here's hoping I don't have weird taste in games...

A massively multiplayer RTS that is essentially a combination of Factorio [1], Rust [2] (the game), Planetary Annihilation [3], and Z [4].

Thematically what I've wanted is the persistent nature of Rust, with the logistic focus of Factorio, the scale of Planetary Annihilation, and a dash of the absurdity of Z (which I haven't played in a very long time so I might be off a bit there). Controlling units, managing supply lines, planning complex offensives, setting up a defensive posture for when you're offline, creating one or more bases to supply yourself, researching technology to increase capabilities, and a very open system for cooperation (or not) are aspects of games that I have yet to see combined. I am for sure leaving out quite a bit here, but if I had all the time and money in the world I'd throw this all together as a weird experiment and see what happened.

[1] https://www.factorio.com/ [2] https://rust.facepunch.com/ [3] https://planetaryannihilation.com/ [4] https://en.wikipedia.org/wiki/Z_(video_game)

I was a loud proponent of this and just signed up at the $10 tier. I'm thrilled to see they put this together but still dismayed at the re-org that resulted in firing (some?) of the staff that maintained MDN.

While I wholeheartedly agree I can't imagine why the author left out a key pillar of the problem: Apple's documentation has become useless and/or non-existent.

- All of the good stuff is in the Documentation Archive.

- New documentation is barely more than the function/method signatures from the API.

- Apple has the resources to do better and did so when they were significantly smaller (both in terms of employees and market cap).

They don't care.

Is it not possible to visit one of their stores and pay with cash?

Unfortunately it doesn't look like the sponsorship program is active anymore. All links 404.

Pledged.

What exists on MDN today is easily worth more to an individual than they pay (in U.S. dollars) for a single coffee in a month. Putting that towards a monthly subscription for a vital resource might not come naturally to people given the present "culture of free" on the Internet, but someone has to be first.

> That would explicitly go against Mozilla's goal of having an open web. A paywall for such a fundamental resource would not be a good thing.

It doesn't have to. The content could remain out in the open.

Although you are correct in that I am suggesting a paywall there are other ways this could work:

- Subscribers could set MDN project priorities in terms of which technologies get focus, topic expansion, expanded example code, etc.

- Early access to incomplete documentation could be given to subscribers.

- Issues with documentation or example code coming from subscribers could get priority treatment.

- Offline versions of the documentation could be subscriber exclusive.

The bottom line is that a tragedy of the commons situation needs to be avoided. Is a paywall really worse than letting bit-rot settle in on the existing MDN content?

> The other areas we have had to scale back on staffing and programs include: Mozilla developer programs, developer events and advocacy, and our MDN tech writing.

> We recognize that our tech writing staff drive a great deal of value to MDN users, as do partner contributions to the content. So we are working on a plan to keep the content up to date.

The stated rationale for the "re-org" (read, layoffs) was to shore up the financials and explore new revenue opportunities. Here is a novel idea that I will provide at no cost:

Charge for access to MDN, structure the legal particulars so that revenue goes to pay the tech writing staff, covers operating costs, and provides the excess to the Mozilla Foundation. Use the resulting goodwill and attention as a lead generation mechanism for whatever other projects Mozilla tries to create and charge for.

Market validation you say? People won't pay for documentation you say? The sole developer of the macOS app Dash[1] makes a fairly decent living selling an app that merely allows you to search freely available documentation offline. MDN has real value that people, myself included, will pay for. Just this week I have referred to MDN documentation at least a couple of hundred times.

Charge. Money. For. MDN.

And pay the tech writers.

[1] https://kapeli.com/dash

Edit: wording correction.

U.S. law is based on English Common Law.

https://en.wikipedia.org/wiki/Common_law#United_States

My guess is that this is a gambit to force Apple’s hand during a time when there is the most intense antitrust pressure over the App Store since it’s launch. If Apple cracks down then it’s just more fuel for the antitrust fire, and potentially evidence in court. If they allow it then it’s precedent that others can use to employ the same tactic. Either way it seems to me Epic is taking a calculated risk to induce change.

> Well, well, well. Some months from now, let's revisit all the sentiments here and see if they still apply when Apple/Google/etc make a change that hurts some startup's bottom line.

You seem to think context doesn't matter. If a startup makes a privacy invasive product and "Apple/Google/etc" put protections in place that harm that product then they've done a service to their customers. This is not a problem.

We can judge their other actions as necessary and in context.

Your question and your attempt at clarification are at odds. The Oxford definition of “soft skills” is:

> personal attributes that enable someone to interact effectively and harmoniously with other people

What are you trying to ask?

The risks involved with executing code are legion, and wanting to promote cultural change in the direction of better safety isn't invalidated by pointing out failings in other areas.

> Downloading a large script and reading it before running it in bash is also hardly good security measure.

> It's much more practical to teach people how to recognize trustworthy sources, and how HTTPS works. Or you can switch to a platform like iOS where there's complete control, sandboxes and reviews.

Downloading bash scripts and inspecting them before running is definitely a good security measure, as is running untrusted software in a VM or container where possible, and generally promoting caution when running anything acquired from the Internet. Even if the source is considered trustworthy there is still the possibility that it has been compromised. npm, pypi, and even the Linux kernel source tree are all examples of this.

In this particular situation the use case is extremely weak. The problem is solved by incorporating dependencies locally, as I pointed out above.

  # The URL is downloaded once, cached forever, and then sourced
  import "https://git.io/fAWiz"

Call me old and cranky, but I thought this naive fad of piping the unchecked contents of URLs to the shell would die off eventually once people got clued in to how dangerous it is. At a bare minimum the contents of any shell script coming from a remote source should be manually reviewed the first time, and then verified to have not changed by comparing against a locally stored cryptographic hash.

This is no better than curl with some automatic caching. At the end of the day why not store your dependencies along side your scripts and then not worry about it changing unless you change it yourself?

This is spot on. My one and only gripe is with this part:

> So how do you keep this kind of monster running? First, you make sure you never allow it to use too much of the CPU, because empirically, it'll mean that you're getting distracted too much and are timing out some requests while chasing down others. You set your system to "elastically scale up" at some pitiful utilization level, like 25-30% of the entire machine.

Letting a Python web service, written in your framework of choice, perform CPU-bound work is just bad design. A Python web service should essentially be router for data, controlling authentication/authorization, I/O formatting, and not much else. CPU intensive tasks should be submitted to a worker queue and handled out of process. Since this is Python we don't have the luxury of using threads to perform CPU-bound work (because of the Global Interpreter Lock).

> You can just pass `--preload` to have gunicorn load the application once. If you're using a standard framework like Django or Flask and not doing anything obviously insane then this works really well and without much effort. Yeah I'm sure some dumb libraries do some dumb things, but that's on them, and you for using those libraries.

It's not always trivial to ensure none of your dependencies have import-time side effects. Sometimes the productivity/business benefit provided by the depedendency outweighs the pain introduced by the side effects.

Do you (or anyone reading) know of any web forums dedicated to U.S. privacy legislation that have a critical mass of members?