aeadio

Aside from rsync.net which was mentioned in a sibling comment, there’s also https://zfs.rent, or any VPS with Linux or FreeBSD installed.

You can consider something like syncthing to get the important files onto your NAS, and then use ZFS snapshots and replication via syncoid/sanoid to do the actual backing up.

This is strictly about how much memory LuaJIT can address on that platform. There’s no “significant performance issues”. If your workload fits inside 2 GiB (IIRC) it will be fast. LuaJIT is a world class JIT.

For a long time a new garbage collector has been an open issue for LuaJIT, which would fix this particular issue, and make the language even faster. Last I checked this was actively being worked on.

Lua without JIT is one of the fastest interpreted languages. In fact it might just be the fastest. LuaJIT is also one of the most advanced JIT compilers out there, frequently beating V8 and others.

There are very valid complaints about Lua. It lacks useful quality of life features. Some of its design decisions grate on users coming from other languages. Its standard library is barebones verging on anemic, and its ecosystem of libraries does not make up for it.

But after using Lua in many places for well over a decade, I’ve gotta say, this is the first time I’ve heard someone claim it’s slow. Even without JIT, just interpreter to interpreter, it’s consistently 5-10x faster than similar languages like Python or Ruby. Maybe you’re comparing it to AOT systems languages like C and C++? That’s obviously not fair. But if you put LuaJIT head to head with AOT systems languages you’ll find it’s within an order of magnitude, just like all the other high quality JITs.

I expected at least a little bit more substance and insight, but the whole article basically boils down to, “if Intel’s fab splits off, they risk becoming another GlobalFoundaries.”

Which, yeah, I don’t think that’s much of a revelation to anyone discussing Intel’s future. There’s no argument put forward that it’s not still the best path for Intel.

Every extant Unix has been rewritten since the original AT&T code, Ship of Theseus style. We still consider them members of the Unix family, because they can trace their lineage directly. One could built a Git repo showing every code change from the original Unix release through modern day BSDs, if only we had granular commit info going back that far.

In fact, it's been partially done for FreeBSD, https://github.com/dspinellis/unix-history-repo

We could in principle do something similar for Darwin (if we had enough of the historical code), which is the core of MacOS, which is based on NeXT, which was based on BSD with a new kernel. That makes MacOS every bit as much a member of the Unix/BSD family as FreeBSD is.

Not a misconception at all.

Mac OS X was essentially a continuation of NeXTSTEP, which is BSD with a new novel kernel. In fact, if you look into the research history of the Mach kernel at the core of XNU, it was intended as a novel kernel _for_ BSD. NeXT went and hired one of the key people behind Mach (Avie Tevanian), and he became one of the core systems guy that designed NeXTSTEP as a full OS around Mach.

Early in the proliferation of the Unix family, member systems went in one of two directions -- they based their OS on upstream AT&T Unix, or they based it on Berkley's BSD, and added their own features on top. NeXT was one of the latter. Famously, the original SunOS also was.

While Sun would eventually work closely with AT&T to unify their codebase with upstream, NeXT made no such change. NeXTSTEP stayed BSD-based.

The other extant BSDs like FreeBSD and NetBSD were also based directly on the original BSD code, through 386BSD.

If I have my history correct, Apple would later bring in code improvements from both NetBSD and FreeBSD, including some kernel code, and newer parts of the FreeBSD userland, to replace their older NeXT userland which was based on now-outdated 4.3BSD code. I think this is where the confusion comes in. People assume MacOS is a only "technically" a Unix by way of having borrowed some code from NetBSD and FreeBSD. They don't realize that it's fully and truly a BSD and Unix by way of having been built from NeXT and tracing its lineage directly through the original Berkeley Software Distribution. That code they borrowed was replacing older code, also BSD-derived.

I imagine if later they try to renege on that public grant, CloudFlare is still shielded.

Asianometry also has a video on the history of the Japanese PC market,

https://youtu.be/CEtgzO-Im8w

Ah, yes. Drew DeVault. The expert in ... developing 30M LOC OS kernels with billions of dollars on R&D investment in a few years with a small team in an experimental language. "Just make Linux 2", it's so simple, why didn't we think of this?!

This is an unusual take considering Drew DeVault actually does have experience developing new kernels [1] in experimental languages [2].

Drew's own post [3] (which the linked article references) doesn't downplay the effort involved in developing a kernel. But you're definitely overplaying it. 30M SLOC in the Linux kernel is largely stuff like device drivers, autogenerated headers, etc. While the Linux kernel has a substantial featureset, those features comprise a fraction of that LOC count.

Meanwhile, what Drew's suggesting is a kernel that aims for ABI compatibility. That's significantly less work than a full drop-in replacement, since it doesn't imply every feature is supported.

Not to mention, some effort could probably be put into developing mechanisms to assist in porting Linux device drivers and features over to such a replacement kernel using a C interface boundary that lets them run the original unsafe code as a stopgap.

[1] https://sr.ht/~sircmpwn/helios/

[2] https://harelang.org

[3] https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-...

Linux did implement an API for safely instrumenting these types of events, eBPF.

Many EDR and other security products are beginning to use it, although IIRC Crowdstrike does not yet.

A reminder that monolithic- vs micro-kernel is a spectrum. You can achieve the benefits of microkernels incrementally, as both Android and MacOS/iOS are proving out -- by moving components into userspace piecemeal, over time.

And you can reap the benefits of microkernel ideas in isolated domains. Apple is choosing to benefit from microkernel style userspace APIs for third party code in particular, because that's a very likely vector for security and stability issues. You simply can't know what degree of testing and safety practices are being employed by third parties, and their crash analytics almost certainly bear out that most system crashes happen there.

Microkernels are not an automatic antithesis of performance. As usual, you have to make informed tradeoffs. Do you keep components X in ring 0, or not? And if you move it out, how do you design the interface between the two to try and mitigate the performance impact of that choice. In the case of Apple with MacOS, additionally, how do you develop the SoC in tandem to make the context switch cheaper?

(Really, Apple's apparent competitive advantage from vertical integration between hardware and software is a farce. There was never anything stopping Microsoft from approaching Intel and AMD and working jointly on making the same kind of improvements at the hardware level for the benefit of the software. They just didn't care enough to do so.)

That the industry gave up on microkernels is not a testament to them being untenable from a performance perspective. It's a testament to the laziness and lack of willpower to advance the state of the art because insecure and unreliable systems were good enough for their customers.

The way our technology looks today is not some utopian extension of all the best ideas we've come up with so far. Choices like monolithic kernels coming to dominate is not evidence that they're a more fit solution. It's evidence that defeatism is the path of least resistance.

When I see Apple do stuff like move to deprecate kexts, I take it as evidence that they give more of a shit about the quality and robustness of their software than the next guys. Meanwhile, we still have Windows forcing EDR components to operate in ring0 and bring down entire industries when a bug happens because they couldn't be bothered to implement a safe API for EDRs in which a memory safety issue -- which we are all acutely aware happen all the time -- won't crash the kernel.

Windows tacitly enabling the Crowdstrike debacle by underdesigning known vectors of failure is not a blameless situation. Crowdstrike has taken more flack than they deserve here, because we've known about issues like this at the platform level, and Microsoft's competitors have even taken the time to fix what Microsoft couldn't be bothered to.

Ideas like microkernels are what you get when people analyze the technical deficiencies in the state of the art, and then go and try to come up with solutions. Of course there's challenges. But that pure microkernels on their own are at a performance disadvantage compared to monolithic kernels is not because that line of thinking is a dead end, but because nobody bothered to put in the R&D to solve it.

A genuine missed opportunity in not including one of the most infamous examples of GNU code quality / needless complexity,

https://drewdevault.com/2020/09/25/A-story-of-two-libcs.html

In principle there's no reason you can't install this next to GRUB in case you're wary. If you're not using ZFS native encryption, and make sure not to enable some newer zpool features, GRUB booting should work for ZFS-on-root.

That said, I've been using the tool for a while now and it's been really rock solid. And once you have it installed and working, you don't really have to touch it again, until some hypothetical time when a new backward-incompatible zpool feature gets added that you want to use, and you need a newer ZFSBootMenu build to support it.

Because it's just an upstream Linux kernel with the OpenZFS kmod, and a small dracut module to import the pool and display a TUI menu, it's mechanically very simple, and relying on core ZFS support in the Linux kernel module and userspace that's already pretty battle tested.

After seeing people in IRC try to diagnose recent GRUB issues with very vanilla setups (like ext4 on LVM), I'm becoming more and more convinced that the general approach used by ZFSBootMenu is the way to go for modern EFI booting. Why maintain a completely separate implementation of all the filesystems, volume managers, disk encryption technologies, when a high quality reference implementation already exists in the kernel? The kernel knows how to boot itself, unlock and mount pretty much any combination of filesystem and volume manager, and then kexec the kernel/initrd inside.

The upsides to ZFSBootMenu, OTOH,

    * Supports all ZFS features from the most recent OpenZFS versions, since it uses the OpenZFS kmod 
    * Select boot environment (and change the default boot environment) right from the boot loader menu
    * Select specific kernels within each boot environment (and change the default kernel)  
    * Edit kernel command line temporarily  
    * Roll back boot environments to a previous snapshot  
    * Rewind to a pool checkpoint  
    * Create, destroy, promote and orphan boot environments  
    * Diff boot environments to some previous snapshot to see all file changes
    * View pool health / status  
    * Jump into a chroot of a boot environment  
    * Get a recovery shell with a full suite of tools available including zfs and zpool, in addition to many helper scripts for managing your pool/datasets and getting things back into a working state before either relaunching the boot menu, or just directly booting into the selected dataset/kernel/initrd pair.
    * Even supports user mode SecureBoot signing -- you just need to pass the embedded dracut config the right parameters to produce a unified image, and sign it with your key of choice. No need to mess around with shim and separate kernel signing.

They don't seem to be attempting to prevent him from publishing his music. They will just revoke parole if he violates their terms. They're not suppressing speech. They're giving him supervised release on condition.

From just the first paragraph, it reads like they aren't trying to approve the release of those songs -- which they wouldn't have the authority to do. They are monitoring his activities as a condition of his parole, which is pretty routine. In this case they're putting forward the argument that he's intent on actively promoting violence with his music, and they are only willing to release him on parole if he curtails that behavior.

I don't know this rapper's music, but this line of reasoning honestly doesn't seem out of the ordinary.

Could be cultural. Go has a lot of exposure in the DevOps / cloud infrastructure space. Lots of stuff like k8s and Terraform (and its providers) are written in Go, and it competes with Python in popularity for internal tooling.

Being able to search in the past for a half-remembered conversation sounds great until you have idiotic, asinine corporate data retention policies that require anything beyond 90 days to be deleted anyway, for some bullshit reason like being open to litigation or whatever and that being subject to discovery.

Well that just doesn't sound legal. In fact, I'm pretty sure Google just got the book thrown at them for this. [1]

[1] https://www.cnn.com/2023/03/29/tech/judge-google-deleted-cha...

What you're describing is called dynamic range compression, and mpv can be configured to do this in multiple ways.

Back in the physical media days, it was pretty common for DVD/Bluray players to include this feature. Unfortunately it's not something that streaming app developers thought twice about. Your TV or streaming box also may or may not have the feature.

Let the industry self-regulate that. You stipulate a reasonable minimum wage, but like most other industries, mid-level and above restaurants need to pay a competitive wage, or talent goes elsewhere. If the going rate post-tip is about $36/hour, then the restaurants can target that as their post-tip benchmark wage.

I can tell you as a different type of talent worker, nobody is trying to pay me minimum wage. Minimum wage is set to ensure there's a reasonable floor on downmarket offerings. When you're 18 and fresh out of school and you work at your local Cracker Barrel, minimum wage ensures you don't get exploited. It's not the benchmark for experienced workers who have picked up a valuable skillset.

You have all these restaurant operators crying that getting rid of tippers puts them out of business, makes their business unviable. Well for one, that's nobody else's problem -- there's no contract, no constitutional guarantee that you're allowed to be in business. Making something economically viable is the whole game.

But it seems like everyone just flunked grade school arithmetic.

The cost is a wash at the end. At mid-range restaurants and above, practically everyone tips the same 18-20% on top of the base cost of the meal. If tipping is made illegal, you can expect meal cost across the board to rise by about this much to make up the difference. It's the exact same cashflow. You can pay a living wage on what you're already charging customers on the final card settlement.

They all seem to be imagining this nightmare scenario where they're forced to raise their menu prices, and that prices them out of the business versus their competitors who, somehow, don't need to do the same.

The law shouldn't cater to business operators with no business sense.

Do you have a source for this? I'm finding it difficult to find concrete information on the new Exclave.

The article is definitely light on details, but my reading is that this pertains to the orange dot painted in the menu bar or notification area when the camera/microphone is being rendered, not to any physical LEDs (which I believe iPads don't have for these components).

Since this is drawn on the screen, typically you might assume system-level malware that's able to get access to window server, compositor, etc would be able to prevent the dot from being drawn, or remove it after the fact.

It sounds as if what they're implying is that there is a dedicated function in a separate hardware chip, outside of the control of the primary application CPU, and not addressable by the system software at all, that paints the dot on the screen as an overlay after the image is rendered by the software display stack, but before it is presented to the OLED/LCD. That would make it very difficult or potentially impossible for even root/kernel-level malware to hide.

That would definitely be noteworthy. And it sounds like a very Apple thing to do -- based on some of the Asahi team's notes about their current hardware, they have an affinity for novel and intricate solutions at the hardware/platform level.

The linked announcement pretty clearly implicates a bug in m1n1, the Asahi bootloader, which appears to have been fixed. It’s beyond a stretch to attribute malice here. Nothing indicates the platform is being locked down. Users simply need to update the bootloader before updating the MacOS firmware.

With OpenTofu exclusive features making such an early debut, is the intention to remain a superset of upstream Terraform functionality and spec, or allow OpenTofu to diverge and move in its own direction? Will you aim to stick to compatibility with Terraform providers/modules?

Is the potential impact of community fragmentation on your mind as many commercial users who don’t care about open source ideology stick to the tried-and-true Hashicorp Terraform?

Is there any intention to try and supplement the tooling around the core product to provide an answer to features like Terraform Cloud dashboard, sentinel policies and other things companies may want out of the product outside of the command line tool itself?

They're afraid of the hypothetical legal threat from Oracle, which largely seems to come from a lot of license misinterpretation and urban myth.

Seems like the only ones that have ventured to ship a ZFS binary are Canonical, and their implementation seems to be done by people that didn't understand ZFS and have no interest in understanding it.

It's really a shame. OpenZFS on Linux really has excellent support and integration, arguably as good as or better than FreeBSD and Illumos, and has this excellent bootloader.

Still, ZFS has good out-of-tree support in distros like Void and Alpine, where the users can take it upon themselves to do a good root-on-ZFS setup and reap the benefits.

Worth mentioning aside Alpine (and other small Linuxes) supporting ZFS just fine, we also have ZFSBootMenu, which is frankly a hell of a lot better than the boot environment experience in FreeBSD.

https://docs.zfsbootmenu.org

From within the bootloader's interactive (fzf-based) menu, you can:

    * Select boot environment (and change the default boot environment)
    * Select specific kernels within each boot environment (and change the default kernel)  
    * Edit kernel command line temporarily  
    * Roll back boot environments to a previous snapshot  
    * Rewind to a pool checkpoint  
    * Create, destroy, promote and orphan boot environments  
    * Diff boot environments to some previous snapshot to see all file changes  
    * View pool health / status  
    * Jump into a chroot of a boot environment  
    * Get a recovery shell with a full suite of tools available including zfs and zpool, in addition to many helper scripts for managing your pool/datasets and getting things back into a working state before either relaunching the boot menu, or just directly booting into the selected dataset/kernel/initrd pair.

    this is a special interpretation added by the shell, and programs don't actually see the ''s. If you put a '' next to other non-whitespace characters, it disappears in the command line that the program will see.

In most shells, you can concatenate strings by placing them directly next to one another. Ie, this forms one string containing the word foobarbaz:

    foo"bar"'baz'

Shell is also famously stringly-typed. All parameters passed to a command (and indeed, even the command itself) are separate strings. So indeed, the final find command from this blog post could also be written as:

    "read" "-r" "-d"'' "line"

This is an important thing to understand if you're going to write any non-trivial amount of shell, especially if you're using a shell variant that opportunistically wordsplits (like POSIX sh or Bash, as opposed to Zsh).

As an aside, this is also an example of why it's good to keep a consistent and clean style, and not unnecessarily shorten in every circumstance where you could get away with it. Mashing command line parameters together makes them a lot less readable, and is meant more as a convenience for interactive usage, than for writing scripts meant to be read and expanded upon later.

Funny to see this on HN. MaLa Project is easily in my top 10 restaurants in NYC. They do authentic and really fantastic Sichuan "dry pot" (aka stir fry). If you're into Sichuan-style cuisine, which leans heavy into layering multiple strong flavors together with spiciness and unique "numbing" from Sichuan peppercorns, it's really hard to beat this place anywhere in the US. It's one of the few places I genuinely miss since leaving New York.

They're on the Michelin Bib Gourmand list, and deservingly so. For my money, their food is better than some Michelin-star places.

I never realized they had such a unique and nostalgic website. I guess that's why it ended up on HN.

Bash and Zsh are both just about as old as one another. Zsh came out less than a year after Bash.

Both derive most of their improvements from ksh, which is why they look superficially similar and many scripts are cross-compatible. Zsh arguably took the language improvements much further than Bash, ie look at [1] and [2] in https://news.ycombinator.com/item?id=39642678.

Bash made the understandable but very regrettable decision of being only a superset of POSIX sh, which means it carries along all the footguns, like word splitting by default.

Zsh is also eminently flexible and scriptable, with many core features (like most line editor functionality) exposed as hooks that custom scripts can extend or change.

Zsh is also notably faster than Bash.

It's one of the great disappointments of open source history that Bash largely took off as the default shell everywhere and the default shell scripting language, despite Zsh being superior in just about every way.

Zsh is quite a bit nicer than Bash for scripting. For one, parameter expansion doesn't word-split by default, so you don't have to haphazardly quote everything. There's also some really powerful features, like the parameter expansion flags [1] and filename generation (globbing) flags [2] that can be combined to do very flexible things. [3]

Zsh also bundles a ton of useful modules that can be used to do things pretty outside the box. Eg, there's a module for creating and controlling a hidden PTY. [4]

Zsh also has some quite nice shorthands for basic grammar, like compact loops and conditionals. Eg, you can do:

    for foo in bar*;
      do_stuff # you don't need the do..done here for single-line for-loops

Lastly, Zsh has this weird reputation for being slow, because the configuration frameworks like oh-my-zsh are absolute dogs. But it's actually among the faster shells, with very respectable script performance that's squarely ahead of Bash. [6] Interactive performance can also be fantastic if you use a less hungry framework or write your own config, and Zsh has many tools to improve speed further, like support for pre-compiling source files [7] and pretty good support for async workers. [8]

Zsh has also been around about as long as Bash, and runs on every major platform and is available in just about every platform's package manager. So the cliche about Bash being available everywhere is just as true for Zsh. Zsh is honestly a much better replacement for scripting, but Bash benefits from already established traction and by being the default shell on most Linux distros.

[1] https://zsh.sourceforge.io/Doc/Release/Expansion.html#Parame...

[2] https://zsh.sourceforge.io/Doc/Release/Expansion.html#Globbi...

[3] https://thevaluable.dev/zsh-expansion-guide-example/

[4] https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#Zsh-...

[5] https://zsh.sourceforge.io/Doc/Release/Shell-Builtin-Command... (see 'emulate' command)

[6] https://towardsdatascience.com/comparing-sh-bash-ksh-and-zsh...

[7] https://zsh.sourceforge.io/Doc/Release/Shell-Builtin-Command... (see 'zcompile' command)

[8] https://github.com/mafredri/zsh-async as an example, but also doable in bare Zsh