Bookmarks was there, like in 2012, but no one bothered to read the docs, and everyone continue to use heavy, non removable branches.

I remember that: for repos ~ 1Gb Mercurial just became unusable. It took half of day just to clone the repo.

That sounds like y'all may have been storing binary blobs and large files with out the right plugins setup.

Just rename root directory of project and double size of your repo Mercurial didn't supported rename, and did delete/add instead, so size of repo grows pretty fast

Run some examples, and it looks like this "High-performance, real-time optimized, super-fast" language is

  ~ 10 times slower than luajit
  ~ 3 times slower than lua 5.4

Not bad for version 0.1.0. lua(jit) is no slowpoke and has had decades of performance improvements.

With this and https://github.com/Beariish/bolt/blob/main/doc/Bolt%20Perfor..., it is indeed confusing without testing it out myself.

That said, somehow I do not believe it is faster than LuaJIT. We will see.

I used brainfuck interpreter https://github.com/Beariish/bolt/blob/main/examples/bf.bolt vs lua / luajit implementations from https://github.com/kostya/benchmarks

Just checked with nbody:

  - still 10 times slower than luajit
  - 2 times slower than luajit -joff
  - but 20% faster than lua 5.4
  - but uses 47 Mb RAM vs 2.5 Mb for lua/luajit

I appreciate the followup here. The brainfuck interpreter isn't meant to be a benchmark notably, it's a naive implementation for the sake of the example.

I did spot some poor code in the Bolt version of nbody that can be changed (the usage of `.each()` in the hot loop is creating loads of temporary iterators, that's the memory difference.)

luajit -joff does perform better even with this change, but I observe closer to 15% than a 2x difference

for nbody 500000 on my i5-9300H CPU @ 2.40GHz

  - 487.41 millis / 2364 kb ram for luajit -joff
  - 770.17 millis / 41712 kb ram for bolt

  770.17 / 487.41 ~~ 1.58 cpu, not 2x, but not 15% either
  41712 / 2364 ~~ 17.64 ram

Where do you get these numbers from? Looking at https://github.com/Beariish/bolt/blob/main/doc/Bolt%20Perfor... doesn’t seem to support these numbers.

They at least clarified it by saying "outperforming other languages in its class". It's a slow class so the bar is low.

For everage user nothing changes - each folder will just have "thumb.db" with all metadata and long names.

https://github.com/picoe/Eto

  - OS X: MonoMac or net6.0-
  - Linux: GTK+ 
  - Windows: Windows Forms (using GDI or Direct2D) or WPF

Gtk

  - Gtk3: https://github.com/GtkSharp/GtkSharp
  - Gtk4: https://github.com/gircore/gir.core

Map looks terribly (like ~5y) outdated.

You need to be specific. It's very much location based in terms of data quality and how current it is. It's great in the SF Bay Area, which isn't surprising given where Apple is based.

> Of course there are many firmware blobs. It's an issue, I would prefer not running any proprietary firmware, but I don't see how it would be a bigger issue in BSD land.

It's closed-source, and it's Linux. There is no firmware for BSD.

> It's closed-source

Of course it's closed-source. I still don't see how it's a bigger issue for the BSDs than for Linux. As in, it's already a big issue for Linux. On Debian they are in a separate section of the repositories (non-free-firmware) that can be disabled. The *BSD could do the same kind of thing. I believe it's up to the *BSD to decide whether they want to compromise this way, but it's the same issue for Linux and for the *BSD. Unless I'm missing something.

> and it's Linux. There is no firmware for BSD.

I don't believe the firmware blobs are Linux-specific, are they? They run on the device, their code is not managed by the main OS on the main CPU of the computer. The device doesn't care about what OS is managing them as long as the OS knows how to speak with them. That the drivers are actually to be written / ported to BSD is another matter.

BSDs can load most firmware perfectly fine. I don't know what you are talking about.

Cool I thought it's specific for linux, so it cannot be used on BSD

Most firmware has nothing todo with the operating-system, it's (most of the time) one level lower, firmware-blobs are (again mostly) bit by bit the same on windows linux and BSD.

I wonder - if there are reasons to use BSD nowadays. It seems, Linux is just better, and the only benefit of BSD is that it is not GPL (so it can used in closed-source software)

I personally use predominantly FreeBSD as a daily driver, but I’m absolutely agnostic about my OS choices. I use Windows 10 and GNU/Linux as well.

Exactly what way do you think GNU/Linux is better?

What I like the most about FreeBSD is the flexibility it offers, similar to GNU/Linux, yet at the same time it feels like an integrated system?

Additionally. The FreeBSD pkg and ports combo beats every GNU/Linux distro I’ve ever tried, and I’ve tried many of them.

Certainly I agree with the author of the blog post in many ways. If I was not using FreeBSD as a server OS, I would (maybe) not use it on the desktop.

huge BSD fan, but this is a debate I've come back to a few times. really like FreeBSD on my server but linux just has so much more happening, esp. on the desktop, there isn't really a comparison.

like maybe if I just needed a simple browsing-word-coding box, but there are Mac offerings there if I want to go fancy, or linux on a commodity Dell/Acer, if I don't, and most of the linux offerings are usable desktops right out of the metaphorical box

Genie is deprecated https://gitlab.gnome.org/GNOME/vala/-/issues/1473