Caligatio

If you can guarantee that the ship can be routinely filled to capacity, it's almost always economical to build the biggest ship you can. These things are often built to the maximum size that will fit into the canal that they transit.

I thought I remember reading that this ship was designed to meet the Suez canal specs.

I assume the ship had a pilot from the canal authority which should absolve the shipping company from liability.

There's another thread about a private sailboat transiting the canal and it mentioned several pilot changeovers; I have to imagine a giant container ship had something similar.

Disclaimer: I know nearly nothing about the shipping/canal business.

There was a single dev response to your bug and it was the above solution.

Your phrasing and tone are quite harsh as others in that bug commented and seemingly agreed by the community judging by the fact you got more thumbs down reactions than thumbs up. Combined with the fact you're not even a paying customer, you really need to evaluate whether your approach was appropriate.

You should read your own bug report for the way to disable auto-updates: either use the portable version or set the ELECTRON_NO_UPDATER=1 environment variable.

I maintain a JavaScript hashing library and the language's handling of large integers is terrible. SHA-256/SHA-384/SHA-512 as well as SHA-3 all use 64-bit primitives so I need to do some hacks to emulate a 64-bit integer. Bit shifting large numbers gets even more nebulous...

I agree I wish they had more detail about the exceptions.

I've been a FPI user for years as a best-effort to reign in tracking but there are a common few sites that just break with FPI (50% of the time PayPal checkout doesn't work). Even if "Total Cookie Protection" is only 98% as effective as FPI, I'm making the switch.

EDIT: FPI = first-party isolation

I regularly push money into my TransferWise USD account from another USD account and they supposedly added direct debit support about a year ago.

There is, it's just really small: 34p or something.

EDIT: 32p - https://transferwise.com/gb/pricing/borderless-send?source=G...

I hadn't heard of this, I'll have to check it out!

Please do not bring the American healthcare mentality to a product that is needed by literally everyone. The minute people can spend 5x to get the vaccine means that people will need to spend 5x to get the vaccine.

kaniko is great but doesn't have feature parity with native docker build. Notably kaniko is missing everything related to BuildKit.

I was heavily optimizing for image size due to certain users being on absolutely terrible connections.

I've had my own run-ins with issues surrounding trying to use Cryptography and hitting compile troubles. A few months back I made a source distribution (sdist) of an internal Python module using Poetry and tried building an Alpine-based container that used it. Because I made a sdist, installing it required Poetry to "compile", and Poetry has a dependency chain down to Cryptography. Because Python/PyPi doesn't support musl-compiled native libraries, I found myself having to install a several hundred MB toolchain to basically copy a Python script to the correct location. I think Poetry now ships a stripped down version of its build engine that doesn't have this dependency so problem solved-ish.

Admittedly I haven't looked at the Cryptography code base to see how much it depends on native code but I wish people made a conscious effort to consider the downstream ramifications of including a particular dependency. I am the maintainer of a quasi-popular JavaScript library and I deliberately wrote my own helper functions for things like base64/UTF-8 conversion just to avoid potential issues (it's been around since 2008 so JavaScript was also a hot mess at the time).

I actually wrote the client cert code back in the day, what problems are you having?

I recently discovered that systemd supports drop-in config files so I'd recommend putting the changed settings into something like /etc/systemd/resolved.conf.d/disable-stub.conf. That way your package manager isn't upset that files it controls are modified.

I wrote a personal blog post about this (https://www.turek.dev/posts/disable-systemd-resolved-cleanly...) to try to help people out.

There still appears to be some confusion but, from what I read, FPI is a superset of this partitioning stuff: https://github.com/arkenfox/user.js/issues/930

I agree with you 100% about Snaps. I only brought them up because one of the common complaints is that the Snap server is not open source. This is why it's weird to me that FOSS supporters would push potential Debian users to Ubuntu where there is even a higher dependency on non-free software.

Regarding non-free support, assuming the firmware is in Debian's non-free repository, Debian already provides support. From their policy[1], distributed non-free software "must not be so buggy that we refuse to support them." That sounds to me like they already offer support (whatever that means for a volunteer-driven project).

So they already release unofficial installers with non-free binaries included, already have a repository that contains non-free binaries, and seemingly offer limited technical support for non-free binaries. Yet they have opted to not readily present these options easily to a potential user.

[1] https://www.debian.org/doc/debian-policy/ch-archive#s-non-fr...

Ubuntu has a checkbox to install non-free codecs, I'm forgetting if that also includes non-free firmware.

With all the hate directed at Ubuntu 20.04 (mostly about Snaps), I don't know why saying "just use Ubuntu if you use wifi" would be an acceptable stance. Given Debian does release unofficial non-free DVD/CD images[1] (i.e. the dirty deed has already been done) and someone proposed a patch to make them more prominent, any resistance to the patch really just seems anti-user rather than pro-FOSS principles.

[1] http://cdimage.debian.org/cdimage/unofficial/non-free/cd-inc...

I feel like distributing the non-free firmware on the installation media but only installing it with user confirmation (they can even have a short pop-up disclaimer about non-free software) is an easy compromise. The open source purists still end up with an install free of non-free software and those that need non-free software can successfully use Debian. Giving people the freedom of (easy) choice to install non-free software does not infringe on others' desire for a completely FOSS OS.

I wouldn't frame this as an "obsession" with user conversion or retention; this is literally just making a product usable by a majority (I think?) of laptop users.

I believe you're talking about a hypothetical but are you saying that the E2E crypto in Signal is flawed and therefore useful as a NSA honeypot?

We've seen from previous subpoena that Signal really only does retain the limited data they claimed and the content is auditably correctly encrypted.

I was actually thinking about this before I posted and discounted email. It has high interoperability but you cannot move your email address to a different provider if you didn't opt to use a domain you owned.

This is obvious when you say it but I can port my phone number between phone companies whereas I cannot move my Gmail address to a different email provider.

At least on Android, there is a local backup option although you need to manually pull it off the device.

I get what you're saying about chat/moderation tools. For some reason I limit my view of Signal to groups of people I actually know. I would personally never use it instead of something like Gitter or community-based chats. I fully agree various chat programs (mostly) each have their own niche.

I should have stated in my original post that there are a lot of features that Signal could add/improve on; my post was meant to be commentary about the implementation critiques levied against Signal.

Your only point I disagree with is backups: there is simply no way for a non-for-profit company that doesn't monetize user data to afford providing cloud backups.

P.S. "New" groups in Signal support up to 1,000 users, did you need something bigger?

You don't need to trust the server with E2E encryption. If you can review and trust the client, the server only has access to the information that the client sends.

Even if they release up-to-date server code, we have no way to confirm that's the code that's running on their servers. People would then complain that they don't have shell access to the servers to ensure the code is what is expected.

I understand what you're saying but I don't know if calling it vendor lock in is quite correct. You can export your list of messages out of Signal and presumably import them to whenever you motivated to do so. Your friends could then join you on the new service and life would continue on.

I am personally unaware of any communication service with a universally portable user identifier and that allows you to freely switch upstream providers other than phone service. I think this what you're talking about?

This is a great example of what I'm talking about. Are you also commenting how you can't see the source of your phone's baseband, Google's services, your ISP's router firmware, WhatsApp's servers, Facebook's service's, etc?

Because Signal's client is open source it's considered a unique-to-Signal downside that we don't have access to the server's source. I feel like some people would bring up the server source issue if someone was asking if it would be a good idea to migrate off of Facebook Messenger.

I feel like Signal is held to a ridiculously high bar when it comes to anything. Is it perfect? No. But come on now; I see other threads on HN where people are debating/bashing their use of Intel SGX, really?

Assuming you trust the client builds (or use a verified build) and verify the public key, all of these arguments go out the window with the exception of exposing your phone number. This situation seems like a prime example of a company (Signal) being so transparent that people need to find fault.

In the ideal world, library developers would properly use the python_requires[1] option and dependency resolvers would correctly identify the latest version of a library that works with the installed version of Python. Unfortunately I have found that is not always the case.

When I make public modules, I personally weigh whether using a new feature is worth losing users stuck on an older version. That sweet spot for me right now is targeting Python 3.6 and using backported modules where necessary (e.g. mypy-extensions). I'm a big type hint fan and type hinting became much more usable in >= 3.6.

[1] https://packaging.python.org/guides/distributing-packages-us...

This is a dishonest comparison. A more appropriate analogy would be you were deliberately trying to run someone over with your car and you ended up hitting a pregnant woman as well. Then your defense is "I'm not a monster, of course I didn't purposely hit a pregnant woman."

NYC is spending $500M/year to clean rail and buses in an effort to combat COVID (https://www.politico.com/states/new-york/albany/story/2020/0...). It's not nearly as cheap as you would think.