aeorgnoieang

The EU claims that even companies not located in the EU are still subject to the GDPR. I don't think the GDPR is applicable in this case tho. It seems likely to pertain to the EU 'right to be forgotten' law(s).

They could arrest their officers if they're ever in Germany (or maybe the EU).

I'm pretty sure actually, uniformly enforcing all of the currently existing labor laws would 'inadvertently deepen abject poverty' too. There are a lot of people working black or gray market jobs (i.e. workers for whom the 'employment' relationship is itself illegal, at least in some aspects) already.

There are tens of millions of people in the U.S. that are not legally permitted to reside here, let alone work. Are you also in favor of actually enforcing those laws and either preventing them from working or deporting them?

> It's almost as though...we as a society continually assess whether the harm from some activity exceeds benefit, and react accordingly?

I do not think that U.S. society, or any country really, could be even approximately described like this, accurately. As just one example, minimum wage laws were originally introduced to prevent minorities (e.g. black people) from undercutting the wages of ethnic-majority workers (i.e. 'white' people). As another, a large number of U.S. states require certification or licensing for people to cut or style other's hair. I am extremely skeptical that such laws or regulations were enacted because a fair cost-benefit analysis implied that such were reasonable.

Those services were, and still are, much worse than Uber and the like. They're not bad in any absolute sense; just relatively bad. I'm pretty sure they weren't and aren't "computer-dispatched" in the same way Uber and the like are either. For one, you almost always had and have to speak to a person by phone, and often more than once, e.g. to receive updates about when a driver could be expected to arrive.

> Others, like myself, think that it should be possible for everyone to have better options available so that nobody does want to work for scraps.

It sure seems like a lot of people will have to continue to work , e.g. for less than minimum wage, and without almost any legal protections, until better options are made available to them.

I'm more inclined to welcome incremental improvements, no matter how modest, than to bemoan everything short of some kind of ideal possibly-possible future.

For one, does "everyone", for you, include every person in the world? Should everyone making a living with less than "better" options be forced to stop working as they are now and wait for those better options to materialize? It seems pretty obvious to me that accepting something less than perfect is better than refusing to accept anything that falls short in the interim.

> So basically desperate people ruin everything?

This is due to people (non-consciously or not-explicitly) holding or believing something like 'The Copenhagen Interpretation of Ethics'.

In a nutshell, it's often better to ignore a problem than attempt to improve it in any way less than perfect, at least in terms of other third parties' reactions.

I think the 'weird' conditions are some combination of there not being other 'riskless' (or less risky) investments and certain institutions being legally required to hold a certain number or amount of 'riskless' or highly-rated (according to the relevant regulators) instruments.

Huh? If investors demand immediately profitability, wouldn't that push companies to "fail fast" even more? The point of failing fast is to spend as little time as possible working on the wrong ideas, i.e. to find 'market fit' as soon as possible.

Time spent designing and architecting isn't free either and, for a lot of people, 'implementing' is the only viable means of testing designs and architecture, and more importantly whether there are any (potential) customers.

An "exit through an acquisition" is a perfectly sensible goal if acquisitions are common or expected. It's pretty common in (some) other industries, e.g. pharmaceuticals.

There's an option in your settings to share your data with their support people and you have to explicitly enable it for them to see your data/info.

But I understand your reluctance nonetheless.

I feel your pain – but I'm a happy YNAB user and I've only ever 'known' the web version. (I'm aware of the desktop versions.) I don't use the auto-import features anymore – they never worked consistently with all of my financial providers and I've found that manually reconciling is much better anyways.

Given how awesome YNAB is for me managing my finances, I'm more than happy to pay the subscription.

Yes, exactly – when I was using GnuCash I tried to create my own 'cash flow' tool using data exported from GnuCash because this was exactly what seemed to be missing in GnuCash. I miss double-entry bookkeeping but YNAB has turned out to be better for me overall.

I didn't like sharing my credentials either but I was using it – until it stopped working for most of my accounts.

I've since stopped using even the 'manual import' and I've found that reconciling to my bank/financial-company statements manually is much easier overall as importing auto-reconciled transactions but then it was basically impossible to then match any specific balance reported by the bank/financial-company.

They claim they have budgets, 'categories', and something I wish YNAB had, 'tags'. Tags would be nice so that I could categorize expenses normally, e.g. 'restaurants', but also group them, e.g. 'trip to X'.

Waivers aren't – just like anything else – perfect protection against (legal) liability. In the U.S. at least, everything can be litigated and even just defending one's self can be expensive.

He asked a question in the form of a comment – I'm pretty sure that's what 'comment' is referring to in the guidelines; not the content of the comment itself.

And you seem to be wrong about by comment about the guidelines. The other user was informed or reminded about the guidelines and we even had a nice little 'comment chat' about them.

Any kind of online forum inevitably requires participants to remind each other of the rules as it's the principal means of enforcing them.

I fully sympathize and agree that downvotes shouldn't be used (here or any other site, generally) to signal disagreement. But they are, and I (mostly) agree with the guidelines about it not being fruitful to ask about it when it happens.

> I’d use it to reserve EC2 instances, for example.

That's a great idea!

From [the guidelines](https://news.ycombinator.com/newsguidelines.html):

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

Containers aren't a magic bullet either. Surely the core of container systems is also "manual work in a for loop". You're right that the default 'ephemerality' of containers is (or can be) a plus but config management tools don't require one to treat one's servers as 'pets'.

> No config management is all-encompassing and so without extreme diligence you will lose the state of your servers over time.

I'm not sure exactly what you mean by "all-encompassing". Surely all of the popular config management systems have 'escape hatches' to let you do anything you could do from a shell, which seems pretty "all-encompassing" to me. But if you mean the config management system don't completely enforce a specific 'state' for managed servers then of course you're correct. Containers don't do that either, beyond periodically replacing running containers with new ones created from a base image (and even that's almost certainly not perfect either).

Unless your container hosts are entirely managed by someone else (and probably even not then, in the fullness of time), you're always going to "lose the state of your servers over time". There's (almost always?) some state somewhere that has to be explicitly managed and thus requires, generally, "extreme diligence".

I do agree that containerization and config management are very different but, like everything, it's 'just' another set of tradeoffs to be made, hopefully depending on one's actual or expected needs and wants.

I'd suggest starting with just scripts, e.g. Bash, PowerShell, anything – that's assuming you have automated builds for both your web app and its components first. (So, automate builds of your app and all of its components first if you don't already have that.)

Pick one cloud provider first and write some setup scripts, i.e. scripts to build an initial (minimal) environment, 'from scratch', for your app and its components, e.g. create a new EC2 instance for the web app, upload your build package to it, etc.. Write the scripts so that any 'secrets', e.g. your AWS API key, are provided as either environment variables or regular command line arguments.

Then, still for the first cloud provider, write some update scripts, i.e. scripts to update your web app and its components.

Assuming your app, or its deployed 'instances', are relatively small and intended to serve a modest load, I'd suggest starting out treating the cloud servers or services as 'pets', i.e. entities you distinguish by name and for which you would be 'sad' if they 'died' (crashed or shutdown). At larger scales, it's often worth treating servers as 'cattle', i.e. a mass of nameless entities, but you probably won't need that at this point or anytime soon. (You'll know better tho.)

As for "containerization and other fancy, related tools that I've been reading on HN in the past couple of years", they're just like any other software – tools that can be used but aren't ever strictly necessary.

Containers are, basically, virtualized OSes, and they can be (very) useful. In my opinion, they're most useful as a way to bundle components of an app with an OS (and other OS components). That you can run those containers in different environments and be reasonably assured they're (mostly) identical can be a big benefit. But there are associated costs too (as with anything)! But if your app and all of its components can comfortably fit on a single (virtual) server, the cost of any changes you need to make to your app to run inside them are probably not worth the (currently) modest benefits.

And all of the other "fancy ... tools" are generally even more a matter of tradeoffs you'll need to make. Once your app, or (production) instances of it, are distributed over several, or many, servers, and you start adding things like load balancers, caching, separate search services, etc., then the benefits of the other 'fancy' tools will start to make more sense.

But, like with many things, it's good experience to directly run into some of the issues that containers and the other fancy tools aim to solve, and really try to solve them yourself with DIY solutions, before committing to use yet another program or tool to do it for you.

Of course, if you just want to learn those tools, and you'd like to use your own app as a 'motivate example', that's perfectly reasonable and valid too. I would recommend tho not to lean on those tools for your own immediate needs unless you really need them.

I'd imagine they are responsible too, not just alone, and that Google is a much more attractive target for GDPR enforcement both because they're larger, have more money, are more visible, but also because they're directly facilitating the "different advertisers" sharing that info.

If Google ceases to provide them the means of readily sharing info then all of those entities will no longer be violating the GDPR, in the scenario anyways.

I think maybe the problem with the comment was that it started with "I think that’s incorrect" but it reads like a non sequitur. The comment to which yours was replying was claiming that matching ads to viewers is itself a privacy violation but your point seems to have been that it – matching ads to viewers – is unnecessary, which, altho related, is a different point and doesn't follow from you thinking that the other commenter's point is "incorrect".

I think you're right in that "site content" is a good-enough proxy for users/viewers/targets for advertising, tho I also readily understand why advertisers would always like more info with which to target their ads.

Even minimal CD is better than doing (or trying to do) the same thing 'by hand'. And adding automated tests is going to be easier with even the rudest CI/CD setup. Some organizations haven't even taken the first steps towards adopting good software development practices:

1. Version control 2. 'Ticket' system 3. Automated builds 4. Automated deployments 5. Automated tests 6. Code review 7. ...

From [the guidelines](https://news.ycombinator.com/newsguidelines.html):

> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.

> Why would it matter that the bidders are able to match up the IDs with each other, aren't they all receiving the same profile anyway?

I would guess that yes, they're all receiving – _from Google_ – the "same profile" but they also are collecting additional info that they can then share with each other and, because they can match profiles exactly, they can access each other's info about specific people.

> Wouldn't privacy advocates consider the sending of the profiles at all an issue?

I'd imagine that the profile Google has and shares is by itself fairly anodyne, but I could be (very) wrong about that. The problem seems to be more (if not entirely) that different advertisers can share info using a common profile ID.

I'd imagine that even a single advertiser would be able to perform a similar 'attack' by, e.g. running multiple different campaigns, but I may be misunderstanding exactly what info is being shared. It's possible advertisers are able to match the Google profiles to specific unique identities and thus are sharing much more than just the info they're collecting directly from their ads.

Maybe "submarines" was intended to refer to submarine drones and not human crewed vehicles?

Whatever could he mean by the mouseover text ...

I think it also pertains to how individual deals sometimes include additional investors or other parties to the deal/transaction, e.g. the parent company partners with another local company for a specific deal and thus creates a separate LLC/LP for just that deal.

Wouldn't you be able to use this to develop whatever and then deploy your code to separate Pi module later?

I think data caps might be the best business tool for ISPs offering services to consumers. After learning about how business Internet services are sold and priced, it's not so surprising that they're more 'rational'.