michelledepeil

I really think you're reading too much into this. Your comment was quite inflammatory (calling certain behaviour disgusting) and had both objectively false info (tailscale is in free for individual use) and subjectively questionable statements ("setting up x in aws is easy").

Going forward, consider properly researching pricing and consider that what you might find easy might not be what the vast majority of people agree with.

Disclaimer: I have no relation to Tailscale, but the company I work for pays for the business tier service.

Comment https://news.ycombinator.com/item?id=31957379 is exactly right.

The post you're responding to wasn't arguing for capabilities, it was arguing for ease-of-use and it was right.

Your comment is pointless and a straw-man argument.

Couldn't agree more. I'm starting to believe in this paradigm and would love to see future iterations. Almost enough so to pay the initial backer tax for this model.

I don't know if it's possible, but if you want a windows experience you might want to try cinnamon. If you're feeling lucky and don't mind a bit of customization, XFCE can do it too.

Pretty cool! But my god, it's still quite some work to reach i3wm-level keyboard control.

I think all of the initially stated requirements work for me with default settings on LM20.2 + xfce (on an x230), however not over a usb-c hub (just a display port cable and power cable directly attached to the laptop). I wonder if the problem isn't really the combination of power+display over thunderbolt.

It's a different aesthetic, but t- and p-series thinkpads are well supported by various linux distros and the experience is considerably smoother (and with better battery life) than 5-10 years ago.

What kind of possibilities do you see?

Right now, I don't see the point - It makes sense to use a special language, with a relatively short learning curve, to develop infra as opposed to executable code. But maybe I'm not thinking big enough.

Linux mint might be a good candidate. The distro also took a stand against snap(-store), and chrome/chromium works fine afaik.

>One example I've seen of a bot automatically creating PRs is dependabot to automatically update dependencies, but in my opinion it adds way more noise than value. Running a command locally to do the updates is just as easy, without any of the noise.

It's just that you need to set up some kind of recurring reminder to do that kind of work, which ends up also being noise, and the work is a chore, nothing more. IMO the noise of a bot emailing you a ready-to-merge PR (usually 1 click) is better than the noise of a calendar event with at least 3 manual steps.

This review is totally correct and I share the hope/idea that this might be the big linux-on-phones jumping-off point. I've been daily driving the Librem 5 with postmarketOS/phosh for a couple of months now, and though I certainly wouldn't give it to my grandmother right now, I can already start to imagine her using a maybe PureOS/phosh on a librem 5-v3 five years from now.

Ha, it seems phosh for the librem 5 might have pushed too many changes upstream to gnome. FWIW those paradigms seem to work great in the mobile context.

I tried dvorak on the moonlander (and have typed dvorak for a looong time before that on regular keebs), but ended up going back to qwerty, and using a layer for the punctuation surrounding the letters. This way you make the most use of the linear layout in the up-down direction, but avoid too much sideways movement and pinky stretching. Check it out here: https://configure.zsa.io/moonlander/layouts/MJXZ4/latest/0

You might move the punctuation even more central to really keep it 4-columned.

This is perfect, because it's an after-the-fact solution instead of me trying to remember to type the right git command in the first place, much like copy-pasting the suggested command is. Thanks for the suggestion!

The final example `yank -- xsel -b` is probably the most directly useful for me, but it still doesn't solve the following problem which irritates me to all hell:

  $ git push
   fatal: The current branch new has no upstream branch.
   To push the current branch and set the remote as upstream, use

    git push --set-upstream origin new

Is there any sane way to copy the perfectly formatted `git push -u` command shown above without resorting to the following eval, which doesn't alias nicely?

  $(git push 2>&1 | grep git)

Okay, fair enough, I guess what I'm getting at is that I find it hard to call that socialism of any kind: it's just corrupt government via bribery (probably).

Sure, the rich might be getting richer, and the poor might be getting poorer, though for all intents and purposes this change seems to affect the middle class, or what is left of it.

What I don't understand is how that ties in with socialism. In modern times, in developed countries, socialism generally pulls the poor up and the rich down (e.g. scandinavia, northern europe, canada-sort-of). How did you reach the conclusion that a relatively right-wing government is socialist?

Some adblockers (blokada at least) do a vpn dns loop thing, and allow you to add host file entries manually, but blokada gave me some issues recently, and is pushing the paid option a lot.

I think it's an interesting point to discuss whether state funding is possible for FOSS software like firefox that creates market competition within a certain segment. It would certainly work well with a more pure view of capitalism, to prevent the monopoly that is the chromium browser (engine). And I also think the EU would be a great candidate for the size/importance of an alternative-to like firefox.

I wrote a more extensive post on my blog, fwiw: https://whatshouldyoueat.com/2020/08/15/mozilla-ideals/

Composability whilst maintaining a monolith codebase. The code in its single imageis used in 3 different environments, without including any runtimes that those environments might not need, keeping the image small. At the same time all code can be kept in a single git repository.

I largely agree with you, best tool for the job and whatnot. At the same time, I feel that due to the time I've spent investigating and experimenting with containers, I'm almost better at getting containers to work the way I want than to run it plain.

So if I was now starting a new project solo, I would probably go straight for containers and never deal with conflicting versions or difficult, hacked-together rollbacks, and I don't think it would take me, personally, more time to set up.

In other words, I think it's a good investment of time to spend, say, a full work-week on understanding containers and experimenting on how to make it work for your use-case.

To be honest, I have a fairly similar situation, I just use a different code-container for local than for production. In production we run some things directly and package the code, whereas in local we package the services, and have the code semi-separate.

In the production environment, I want the code image to be set in stone, that way a deploy or rollback will go to the exact git commit that I expect. So the CI-script for deployment is just a `docker build` command, the dockerfile of which clones a specific commit hash and runs dependency installation (yarn install, etc.), then sets the image version in the production env variables. The code is then encapsulated in 1 image, which is used as a volume for other containers, and the runtimes are each in their own container, connected by docker-compose.

For local, it's a much heavier code image that I've prebuilt that contains our current version of every tool we use, so that the host machine needs nothing but docker installed to be able to do anything. The services that actually display stuff on the screen (Node.js) run as their own container with their own processes, but you can hop into your code container (used as a volume for the services) and try out command line Node stuff there, without fear of killing the procs that show your local environment.

It took a long time to reach this point, lots of experimentation, but it's now pretty lightweight and pretty useful too.

I won't be the first to tell you that docker + macos is a constant struggle. It can be done, and I support about 10 developers using about 10 simultaneous containers on macos. My troubleshooting workflow right now is the following:

- Is the container throwing errors? A running container somehow repeatedly throwing errors on its non-main process restarting will eat up all resources of any machine, any OS;

- Is the container trying to sync a folder or datasource between the container and the host? Especially on macos, using docker for mac, this will hurt your performance. Solutions are in the form of specialized syncing systems (docker-sync)[http://docker-sync.io/] or manual syncing using rsync or unison;

- If you have many running containers, it can be useful to spin up a linux VM (ubuntu, debian) in virtualbox, then run the containers in there, finally using a tool like unison to sync dynamic content (the changing code) to the vm;

- Is 1 container using far more resources than the others? Is this strictly necessary? It is possible, in docker-compose at least, to limit certain resources for containers (it's probably also possible without docker-compose, just using docker run) https://docs.docker.com/config/containers/resource_constrain....

Probably the dynamic content synchronisation is the biggest resource hog, and docker-sync has really helped with that in the past, plus it doesn't require different setups between linux and mac hosts, i.e. you could use the same docker-compose.yml file.

It doesn't hurt to inspect whether the host machines are potentially running other heavy services, such as heavy electron apps or a million open tabs in browsers. I've had to tell some devs to perhaps not use their work machines for personal chat applications (but just having their phone open then) because those applications were using >3GBs of RAM each on a 16GB ram machine, leaving very little for any work-related processes.

I can opine based on my current position, where I interact with both containerized and non-containerized infra, specifically a docker-compose-like system versus direct installs on AWS EC2 instances. In my opinion, a well made containerized system is far superior an experience:

- Deploy times are certainly slower, up to 50x slower than non-containerized. However, we're talking 30s deploys versus 20 minute deploy times, all-inclusive. The sidenote here is that you can drastically reduce containerized deploy by putting in some effort: make sure the (docker) containers inherit from other containers (preferably self-built) with executable version that you need. For instance, you might inherit version X of program A and version Y of program B before building only a container with version Z of program C, as A and B barely change (and if they do, it's just a version bump in the final container). Even better, just build a code container during deploy (so a container with essentially only code and dependencies), and keep all the executable as separate images/containers that are built during development time;

- Containers do allow high-speed fixes, in the form of extremely simplified rollbacks. It is built into the entire fabric of containers to allow this, as you just change a version number in a config (usually) and can then rollback to a non-broken situation. Worst case, the deploy of fixed code in my case does take only 20 minutes (after the time it takes to fix/mitigate the issue, which is usually much longer);

- Local environment is _so much easier_ with containers. It takes 10 minutes to setup a new machine with a working local environment with containers, versus the literal hours it can take on bare metal, disregarding even supporting multiple OS'es. On top of that, any time production wants a version bump, you can start that game all over again without containers. Most of my devs don't ever worry about the versions of PHP or Node they are running in their containerized envs, whereas the non-container system takes a day to install for a new dev.

Containers can be heavy and cumbersome, but in many cases, a good responsibility split can make them fast and easily usable. In the specific case of docker, I find treating the containers like just the executable they are (which is a fairly default way of dealing with it) works wonders for the easy-and-quick approach.

Out of curiosity, why not make the app source-available?

Just checked and the instances are running Amazon Linux AMI 2018.03, which has `ID_LIKE="rhel fedora"`.

EDIT: I changed the title of this post to reflect that fact.

I'm reminded of a recent article about a criminal being caught because his brother had used 23andme.

The ELI5 I always tend to fall back on is the example of the Dutch Jewry. The tale goes that The Netherlands had a beautiful list of all its citizens, their names, addresses and their religious statusses neatly tucked away in a locked filing cabinet behind a locked door in the town hall.

Come 1940 the Nazis had a beautiful "leaked database" to use as a reference.

That's just because tea drinking is currently socially acceptable. As examples, in a western context: what if it wasn't tea bags but used condoms? In a middle-eastern context: empty beer bottles?

Worse, you can't predict what will happen to society and its rules, up to the point of "normal" stuff becoming illegal. Take as an example the (new) laws on pornography in the UK. What if have an under-18s minor in your house and your trashbags are full of pornmags?

...and the same thing continues in these comments: something totally mundane posted on the internet being dissected to within an inch of its life. The whole point of the article is that random stuff on the internet becomes world news, but that seems lost on the HN crowd, who focusses more on the iPad bug. Actually, maybe I'm not surprised that has become the focus here.