prepperdev

Yes. That very example shows why itis hard to write fast program in Ruby. It's not even the interpreter (which is slow), but it's that Ruby is pure magic.

I was never able to understand what happens, when I looked at a particular snippet of Ruby code, if it was not me who wrote it. With Go, understanding others people code is a trivial task.

Craigslist approves: https://sfbay.craigslist.org/

Monorepos are underappreciated.

- Dealing with cross-repositories changes is unproductive.

- Relying on external servers (git / npm / whatever) is risky.

- Visibility of what goes to your servers is never easy without having everything in one (well-organized) monorepo.

Monorepos solve it all, without adding any issues, if done right.

Essence: "A single associate assigned to a specific production line working between the production dates specified (12/14/2020 – 12/21/2020) was found to be using an improper torque wrench technique".

A case for using more robots, I guess.

The counterpoint is valid (rising seas don't help), but then we have Saint Petersburg ([1]) that's literally build on top of swamps and occupies multiple islands. It has a first class subway ([2]). It's a little deeper than regular subways, but it exists and works really well.

1. https://en.wikipedia.org/wiki/Saint_Petersburg

2. https://en.wikipedia.org/wiki/Saint_Petersburg_Metro

Amazingly, the chat example still works:

  $ ssh chat.shazow.net
  * prepperdev joined. (Connected: 35)
  [prepperdev] anyone here? :)

What are the limits for the number of layers? 176 seems like a large enough number to believe that a few thousands are a possibility. Is the tech any close to a bottleneck, or they will keep growing them up?

That would be up to a specific OS to decide which guarantees on stack size limit would it like to provide. But I agree that it's a valid concern, and not all possible vDSO implementations are reasonable.

vDSO is a good way to mitigate issues like these. It's also a better stable ABI than libc, and easier to maintain than pure kernel ABI (like Linux does), because nobody forbids the kernel to inject different vDSOs to different binaries, if a need arises.

vDSO is also a language independent construct, so there's no special treatment for any favorite language, be it C (OpenBSD), C++ (Windows) or Oberon OS (Oberon).

vDSO: https://en.wikipedia.org/wiki/VDSO

This is covered by their FAQ: https://gemini.circumlunar.space/docs/faq.html, Section 2.5 "Why not just use a subset of HTTP and HTML?"

What I meant is having markdown pieces within code regions in a text/gemini doc.

Imagine a code review tool that tries to show a diff as text/gemini.

Gemini is a cool piece of simple tech. I had a genuine pleasure reading the spec: https://gemini.circumlunar.space/docs/specification.html

I've entertained an idea to build a set of tools for contemporary development (version control, code review, CI, etc) which would only speak Gemini. That would be both the UI and the API.

Blockers came fast:

* no way to upload anything that exceeds 1024 bytes,

* escaping is subtly broken and so it would be impossible to review code written in Python or Markdown (triple quotes)

* No text editing capabilities, pretty much.

Which is fine: Gemini is great because it's restricted. It's nearly impossible to abuse. It will find its users, even if it would not be me.

Yes. I definitely had the vibe of 'Get the Facts' from the Microsoft Linux-smearing campaign circa 2004 ([1]).

1. https://en.wikipedia.org/wiki/Criticism_of_Linux#Criticism_b...

First of all, kudos for trying to find new ways to fund open source. Those are needed.

This approach might work well for issues which require a lot of thought, but produce a simple fix and can be easily merged

This might go horribly wrong if outside contributors try to implement a major feature to a project which they don't have a good mental model for, produce a large patch that may get rejected by maintainers, or end up being rewritten-by-code-review, which would cost such maintainers more time than if they implemented the feature in the first place.

It would be interesting to follow!

Bloomberg maintains an excellent dashboard that tracks vaccination in the US and worldwide ([1]). It shows that California is one of the slowest states with only 37% of received vaccine administered. Top five states are North Dacota (77%), West Virginia (74%), Oregon (61%), South Dacota (61%) and Texas (60%).

1. https://www.bloomberg.com/graphics/covid-vaccine-tracker-glo...

Excuse me?

While my account is relatively young (13 days), it's not one day old. You can also look into my comments over this time. So, the accusation is clearly off.

snaps are tied to the proprietary Ubuntu store and they are not available on all of the Linux flavors. For instance, I don't see snapd on Alpine Linux:

  $apk search snapd
  $

Not cool, I think.

I don't believe it's a joke. It still might be a deliberate lie (a random twit is not a real source of knowledge), but so far this is consistent with what we already know. See https://news.ycombinator.com/item?id=25769730

Copying their requirements as text (original grammar preserved, including GB and Gb confusions).

It's a good glimpse of what unlimited cloud budget does to companies. I quote:

"""

* 40x i3.Metal instances (64 vCPU's, 512 Gb ram (more ram, of course, better for those)), 14 Tb nVME e/a (Scylla cluster)

* 70-100x (96 vCPUs, 768 GB RAM) - 4 Tb nVME e/a (PSQL cluster, could use more RAM and CPU, but not easy to get)

* 300-400 various other instances, less picky, generally 8-16 cores w/ 32-64 Gb of ram as available

* Internal traffic ~300-400 Gb of traffic/minute

* External traffic ~100-120 Gb of traffic/minute

"""

Recently, I migrated my personal dev laptop from Ubuntu to Alpine Linux. It took a day, but everything works now, including hidpi stuff.

No big issues so far and I am in the process of migrating my home server to Alpine.

Debian policy is very sane (no network access during build), but it does seem like modern software just assumes that the Internet is always available, and all dependencies (including transitive) are out there.

The assumption is a bit fragile, as proven by the the left-pad incident ([1]). I hope that whatever the outcome of the discussion in Debian will be, it would keep the basic policy in place: not relying on things outside of the immediate control during package builds.

1. https://evertpot.com/npm-revoke-breaks-the-build/

Key quote: "We have become extremely dependent on conda and conda-forge. We must think of their sustainability."

Then it talks through the steps being taken to reduce dependency on Anaconda Inc. While the company proved to have a lot of goodwill in the past, there's always future: it gets acquired, and the new owners might not be as well meaning as the current ones.

It really depends on how small or large your organization is.

If it's a single repo with a single branch, sure. No need for explicit backups.

If it's tens of repos with multiple important branches in each, then it would be very dangerous to assume that developer machines have all of them.

That's not necessarily true. If your organization has tens of repositories with multiple important branches in each, all odds that at least some of those branches are lost.

Proper backups of all repos are an answer, of course.

Yes, as answered in another branch, it's possible and reasonable to setup continuous / daily backups, if you're using a hosted Git service (Github or not). This will mitigate the risk of losing access to the code.

It's not advised for these Iranian developers to use any Github-specific features, such as issues, wiki, CI, because losing them will cause disruption / knowledge loss.

And then the reason to use Github specifically, instead of something else is quite low.

Yes, making daily on-premise backups would mitigate the risk of losing source code.

That applies to everyone, not just Iranian developers: setup daily backups of all your code.

That sounds great, but it's a very fragile state of things.

While it certainly makes lives of Iranian developers easier, it does not make it a good idea to put their code there: laws change, and quickly sometimes.

From the company perspective, it's an arbitrary disruption. It could happen to any company.

While it's certainly very convenient and economically reasonable to use cloud services for development and production, every company should have a plan B.

In this case, it's an absolute must to have daily backups of all repositories / all branches which are stored on premise. If your company is not doing that, you play the lottery of losing access to your own source code.