Goroutines are amazing and extremely easy to use. You should include them wherever possible. But always be careful of Data Races

Goroutines are amazing and extremely easy to use. However, you should absolutely not include them wherever possible. Using them can in fact slow down a program for which they are not suited (context switching still has a cost), and they introduce non-trivial complexity.

Still, it’s nice to see a post with some start-here optimization ideas; many Go optimization articles assume a deep experience with Go and can be daunting.

To be fair, it is a very long-winded post. I think it’s not an uncommon use case, though, and so deserved a robust sketch of the desired solution; Farmville and chat are sideshows, and what the people left on Facebook are really there for are the Walls.

Compiling has never been the hard part. The challenge is making it through the entire configuration menu system before succumbing to the urge to gouge your own eyes out with blunt sticks.

Once that’s done, kick off make take a long break; it’ll be compiled by the time you get back to it.

I hear build times are getting longer with the Rust parts, though, so do it soon before you need mainframe access to get a compile within your lifetime.

There are some excellent apps out there, and by and large they look and work better than commercial apps, IME. So I disagree with the assertion that I have to stay with commercial software.

What I was asking for, in my post, was not which apps have better UX than Facebook, but rather which of the very many OSS, federated (although, not necessary for my use case), self-hosted platforms fit the specific use, and ideally with a straightforward iOS mobile app. Doesn’t have to be pretty; just has to be able to quickly take and post photos to a private channel/community/wall.

Circles really is quite nice in all respects. I think they’re hindered by their choice of backend. I’ve been using Matrix for years, and key management has always been a hot mess. I wouldn’t be surprised if the issues we encountered were related to Matrix’s god-awful and buggy PK negotiation & management process.

The AMD graphics driver is reputedly the biggest that mainstream Linux users will encounter, approaching six million lines of code.

That does seem a bit … excessive.

It sucks the same way Python sucks. Some people just really don’t like indentation-based syntax. I’m one of them, so I dislike both formats. However, if you groove on that sort of thing, I don’t think YAML is any worse than any other markup.

Oddly, I get along with Haskell, which also used indentation for scoping/delimiting; I can’t explain that, except that, somehow, indentation-based syntax seems to fit better with functional languages. But I have no clear argument about why; it’s just an oddity in my aesthetics.

djot for text markup. It addresses a lot of the issues in Common mark (and of course far more of the issues of Markdown).

I love that there’s someone out there who’s that passionate about JSON.

Love, love, opus. It’s a fantastic format.

Minnesotan here. Can confirm that 32 is still long-sleeve shirt weather.

I regularly see people here walking into a store from the parking lot in T-shirts, in 32° weather. Wind chill makes a far greater difference. 38° from wind chill is far colder than 32° with no wind.

The week-of-year is far more relevant in Western Europe, and is used quite a bit in business. I have a Junghans watch that has a week complication.

It’s an important format outside of the US, and gives ISO-8601 an edge as a standard of conformance.

Shucks, I switched from screen to tmux over a decade ago, simply because (a) screen wasn’t a ubiquitous tool, and (b) tmux was superior in almost every way. I haven’t encountered screen in the wild in years.

a) is still important; I like and use ripgrep and fd, but grep and find are still useful because they’re always installed, everywhere that’s even halfway POSIX. ripgrep and fd aren’t everywhere - e.g. BusyBox. But screen isn’t in that core toolset, so there was little reason to hang on to it.

I agree, it’s a great idea. The limitation is that the maximum amount of data a QR code can hold is about 3kB. Assuming the encoded data is compressed - either mostly ASCII and compressed, or a custom serialization format referencing external lookup tables - you could reasonably fit around 10kB of debugging information into a single QR code. That’s not too shabby.

This is very true; that’s just plain Capitalism, and the government takes advantage of that through simply asking for the data.

It’s a great reason to never use MS or Apple software.

I’m stuck on Android, which is no better, at least until someone sells a phone that is reasonably usable as a reliably daily driver. So, I assume everything going through my phone is surveilled. It’s the price I pay for not wanting to limit myself to a dumb phone; a minimalist phone that will allowed me to use a P2P encrypted chat client would be sufficient; I’d even accept Signal, although I’m not a fan. But phones like the Light Phone are just too dumb, and none provide any sort of encrypted chat. Linux based phones (or, a phone-oriented Linux distro) are almost there, though, and I’m ready to jump when one gets a decent review.

Sure. If anyone is willing to put in that effort; I’m not going to audit all that code.

Does Deepin have its own package sources? B/c if so, you also have you audit all of the third-party packages for trojans, too.

Mine is 3-pronged:

1. btrfs + snapper takes care of most level-1 situations, and I take a snapshot of every /root change, plus one nightly /home snapshot. but it’s pretty demanding on disk space, and doesn’t handle drive failure; so I also do
2. restic + USB drive, which I can cram way more snapshots onto, so I keep a couple of weeks of daily snapshots, one monthly snapshot for a year, and one snapshot per year, going back several years. I currently have snapshots from my past 3 computers on one giant drive. However, these drives can also fail, and won’t protect me from burglary or house fire, so I also do
3. restic + BackBlaze. I just take a nightly snapshot for every computer and VM I manage. My monthly B2 bill is around $10. The VMs don’t change much, and I only snapshot data and config directories (only stuff I can’t spin up fairly quickly in a container, or via a simple install command), so most of the charge comes from a couple of decades of amateur digital photography, and an archive of all our digital music (because I’ll be damned if I’m going to spend weeks re-digitizing all those CDs).

The only “restore entire system b/c of screwing up the OS” is #1. I could - and probably should, make a whole disk snapshot to a backup drive via #2, but I’m waiting until bcachefs is more mature, then I’ll migrate to that, for the interesting replication options it allows which would make real-time disk replication to slow USB drives practical; I’d only need to snapshot /efi after kernel upgrades, and if I had that set up and a spare NVME on hand, I could probably be back up and running within a half hour.

The difference is that laws in China require companies doing business in China provide the Chinese government with means to access all data crossing Chinese borders or involving persons of interest. You can read the DSL of China yourself; and consider that nearly every executive of any significant Chinese company also holds an office of some sort in the Chinese government, there are a vast number of Chinese nationals who are considered “persons of interest” to the national security of China and therefore fall under the DSL purview.

Any company building or selling software in China has to provide the Chinese government with access to data collected in China, or outside of China if it involves persons of interest for national security. Like I said, find the DSL and read it yourself, or read an InfoSec analysis of it from a company you trust - you don’t have to take my word for it.

This immediately puts Chinese software into a different category of risk than non-Chinese software. Of course, the US could twist arms to get companies to put backdoors in software. But it’s a false equivalency to say that they’re the same. When the US does it, they have to do it covertly, and there’s always the risk of a leak. When Chinese companies do it, they’re doing it because Chinese data laws require them to.

There are already quantum resistant algorithms available as open source libraries, and some tools which already use them. It’s nice to see some standards emerging, although I’ll be more confident after external reviews pronounce them “clear.”

Hi! Boy, I can’t wait to see the other comments.

1. My database choice starts with any dependencies. Of any core complement has a preference (or requirement) for a particular DB, that’s the one I use. DB admin is probably my least favorite thing in the world, and having to manage multiple can put me entirely off a project. For this same reason, if I have a completely free choice, I’ll choose a NoSQL DB, as they’re almost always easier to admin (with the almost singular exception of embedded DBs like Sqlite). But I’m also a little biased against SQL because (a) it’s a domain specific language with some pitfalls not hard to hit with sufficient complexity; (b) each DB implementation has dialect specifics which are irritating when you have to bounce between different DBs; and © I’m simply neither confident in my knowledge, not have interest in maintaining expertise. I acknowledge the strengths of a SQL DB; it’s simply not where I want to spend my time.
2. Yes, DB containers are significant. If you only use PostgreSQL, and you’re for some reason running multiple instances, those containers will share the same images. This will only save you disk space, but with people basing their images on, e.g. Ubuntu, container image sizes can be significant - GBs of space. However, if space isn’t a concern, this may not matter.
3. It’s probably likely that your DB upgrades will be driven by your proglang DB interface library requirements. Personally, I wouldn’t upgrade the DB unless there’s a CVE or some other external demand, such as when the library requires it. And - yes - it can easily break your application, like any dependency. Rails is particularly horrible about tight DB version coupling, at least on PGSQL.
4. If you’re careful about the SQL you craft; or the ORM or abstraction library supports it; and all your tooling (upgrade/rollback/DB initialization) supports it, then maybe you can swap out DBs with little trouble. The data migration might be the hardest part, and the older your application gets, the more fraught swapping DB backbends will become. I’d suggest that by doing this, you’re exposing yourself to a number of possible essentially runtime bugs from incompatibility or simply differences in how DBs function. You may be confident in data integrity in case of programming bugs with one DB, only to discover difficult to track down bugs because the DB handles errors differently. You might have to change libraries to use a different DB, introducing more variables and potential runtime bugs.

You can add another abstraction layer to your DB interface, and write a bunch of tests for it; if I really thought I’d ever need to change DB backbends, that’s what I’d do.

Redis is a very simply DB for very simple data. It’s a persistent key/value cache. It’s not meant to fulfill the role of a relational or structured data database. It’s meant to be for fast lookups of simple data. It has a trivial query language. It’s a hash map.

What? Why?

I never noticed it either, but now that I have… I don’t know why a Reddit community would have a Barbie movie ad, either. Was Barbie produced by Reddit? Does this community only repost Barbie-movie Reddit content?

What makes this an ELI5 question?