radiowave

I'd guess the motivation was to experiment with different string constructions, given the string shown in the video. Gut core is not common these days, and I don't think I've ever seen a wound string with alternate windings in different materials.

I think buro9's recommendation is pretty sound. I have some smaller/older/cheaper KEF speakers on my desk, where I don't have the space to put the larger PMC speakers I would normally use. They have a dual-concentric design that is clearly related to that of the LSX and LS50, and (at the risk of "dancing about architecture") I've been very impressed with the clarity and directness of the sound.

On the basis of that experience, I'd certainly have the LSX/LS50 on my shortlist if I was looking for speakers in that size.

What's supposed to happen with ZFS is that if the rest of system needs more memory, ZFS should back off and release some of the memory that it's using. It can do this because most of its memory use is just caching, and while there no doubt is a limit to how far you can take this, I never heard anyone question the effectiveness of this on the OpenSolaris/Illumos implementation.

I don't follow FreeBSD closely, but if memory serves there was a concern, particularly in the early days of the ZFS port, that their implementation couldn't be counted on to release RAM fast enough, if the system suddenly came under significant memory pressure. Hence the advice was to always run with more-than-sufficient RAM to minimize the likelihood of getting into low memory situations. I think this is a significant part of why FreeNAS considers 8GB to be the minimum supported configuration.

So it seems to me that this isn't really about ZFS's RAM requirement, rather it's about hedging against the volatility of the RAM requirements of other software on the same box, in case ZFS can't back off fast enough.

These days I run ZFS on Linux, and I remember about 4 years back spinning up some bulk data processing job that was configured to use 14GB of RAM, on a 16GB box, and watching ZFS's ARC RAM use drop in a single second from 5.5GB to 0.5GB. So I'm satisfied that for my purposes, on ZoL in recent times, this isn't an issue I need to worry about.

My first ZFS box (running OpenSolaris 2008.11) ran on 512MB, sometimes including a Gnome 2 desktop. It wasn't fast - I didn't need it to be - but it absolutely did work.

Ah, that's good news. Thanks.

Off the top of my head, the exception to this is functions (i.e. that you declare inside Postgres), because the function body is really just a piece of text, in any of a bunch of different languages. So if you have a function which refers to specific database objects that are being renamed, you'll also need to update the function definition with the new names.

I went through much of this a few weeks ago, and this article would have saved me quite a bit of time. Like others here, siglen is new to me, so I'll have to have a play around with that.

One thing that bothered me was how cumbersome the queries become once you start having to concatenate and coalesce a whole bunch of columns together. Postgres has a variadic function called "concat_ws" which ought to be useful here, especially as it implicitly coalesces NULL inputs to empty string. However, it's not declared to be immutable, so can't be used in an expression index.

The solution (from Erwin Brandstetter's answer on Stack Overflow) is to use an immutable variant of this, constrained to only handle data of type "text".

https://stackoverflow.com/questions/54372666/create-an-immut...

With this immutable concat function in place, and a trigram expression index making use of it, the WHERE clauses become a lot more concise, for example, the clause in the final query of the article reduces to just:

  WHERE immutable_concat_ws(' ', asin, reviewer_id, reviewer_name, summary) ilike '%' || input.q || '%'

Row-level security, I assume.

Not sure that I qualify as an expert, but in the case of Postgres the choice was probably influenced by the fact that readily available, distributed, fault tolerant, key-value storage wouldn't exist for at least another decade.

"Aright" is probably correct, if a bit archaic from our perspective, but "be" is almost certainly OCR error (plus lack of proof reading), and not the only one.

Long live the Grauniad. (That being a nickname given to The Guardian due to its tendency for typos.)

Mikrotik HAP AC2 as router and wifi, with HAP AC providing extra access point. Fiddly to set up, but solid and trouble-free since.

Used to use Ubiquiti Edgerouter, until it failed. The Smart QOS feature was pretty good. Used to use Unifi for wifi, but always struggled with clients getting stuck communicating with the most distant access point.

(Edit: In case it's relevant for some, I should also list: a Draytek 130 to adapt perculiar UK PPPoA broadband to PPPoE.)

> Just install our 350mb Electron app...

Added bonus: repeat this process monthly to ensure you stay up to date!

No, that would be an ETLA - "extended three letter acronym".

As someone who works in the manufacturing of steel components for marine use, the most surprising thing for me is that there's no mention of any quality-system auditor being involved. Did the auditor miss this? Is there no auditor? If so, why was their customer (the prime contractor) willing to tolerate this? Why were the company's insurers willing to tolerate it?

No doubt the metallurgist was grossly irresponsible here, but I do wonder whether they might be making a song and dance about this one aspect to distract from a whole chain of careless practice.

Because it was capable of running the existing (unchangable) software.

For a transaction processing workload (where hitting indexes is the all-important thing), that's exactly right. But if you have more of an analytic workload involving sequential scans, Postgres definitely expects the underlying storage system to be handling at least some of the caching.

However, (or unless things have changed recently) you have to license at least 4 cores. The 2-core pack only exists so you can use it in conjunction with 4-core packs to license (e.g.) 6 cores.

An interesting dynamic here is that, having read Yeggie's article years back, I regarded Smalltalk as being somewhere towards the conservative end of the axis (at least, in comparison to other dynamic languages.) E.g.: variables declared before use, no truthiness, very few automatic type conversions. It results in a system with a high degree of internal consistency.

And yet, the goal of the language is to enable activity at the liberal end of the axis.

So maybe there's a more subtle goal: you have to enable someone to make a mess, but also equip them to get out of that mess into something more structured, as and when that becomes useful.

As a counter example, spreadsheets are wonderful for making a messy solution to certain kinds of problems - but how do you then it them into a spreadsheet that isn't a mess? I don't know that I've ever seen that happen - it seems like the right means of abstraction and combination to enable that to happen just don't exist in spreadsheet-land.

It happens that you don't get the insight into how to do something right until after you've made a few messes. I think Kay takes the view that the act of generating that insight is ultimately more valuable than the act of producing any one particular software artefact.

> Why should the database be the input sanitizer, though?

More in the realm of traditional business IT than what HN is focused on, the database is often the point of integration between several different systems, with views and triggers providing the means of abstraction at the interface boundry.

Of course ideally all such systems would only ever profer perfectly valid data, but in practice ...

If you're at all likely to be defining views that contain any of these columns, I would strongly advocate using text with the check constraint, rather than varchar. The reason being: if you ever need to increase the column's maximum length, in the case of varchar you will be prohibited from making this change because it violates the data type dependency between the table and the view.

To cope with this, in the same transaction that you're increasing the length of the varchar, you will also need to drop and recreate all such dependent views (and any other views that depend upon those views, etc).

This is not fun.

In comparison: increase the maximum length of the check constraint, job done.

Workstation computers can be a joy of simplicity, as they're intended to be very easy to service. But this comes about because they're full of proprietary parts, so IMO you've got to be happy to accept them as-is. Otherwise, as the article shows, you've got your work cut out.

I'm a PC tech who grew weary of figuring out which panels need to be removed, cutting myself on sharp metal edges, trying to distinguish between the five different types of screws needed to hold the various internal components in place, having to remove the CPU cooler and (what feels like) a quarter mile of cabling to be able to replace the power supply, etc, etc. And as it happens I've just replaced my old HP Z600 with a Z620.

Note that it doesn't play well with ZFS, but see here for workaround: https://old.reddit.com/r/Proxmox/comments/m9ce8s/got_docker_...

Likewise, have run it for years on a bunch of machines, never had a problem. I think I've got at least one that's been dist-upgraded all the way from a 4.x release to the current 7.0.

It turns out to be the capital 'X' in X86 that is the problem. The same URL but with a lowercase 'x' works fine. Presumably someone in the Pharo team need to fix whatever image metadata the Pharo launcher is working from.

Seconded. These are my default choice for pfsense (and probably opnsense in the future).

Only issue I've had is that if it's a J1900 Celeron CPU, ensure you have the machine set to boot via UEFI before installing. (IIRC there's an open issue for FreeBSD installations failing to legacy boot on J1900 boards.)

It appears that they're in the 'build' folder for the platform in question, e.g.:

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/b...

Relevant quote from one of ZFS's primary designers, Matt Ahrens: “There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. ... I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS."

I'm not an IRC person, so I have no idea myself about any of these things, but I notice that this blog post links to an earlier post where the author speculates about what's driving these changes:

https://ariadne.space/2021/05/20/the-whole-freenode-kerfluff...

Yes, it can be. The reason it's built in to the mic is to protect the mic's output transformer from distorting when recording louder sounds. Most newer/cheaper designs of condenser mic use solid state outputs (unless they're deliberately apeing a classic design) which typically are less easily saturated by loud bass sounds.

I'd guess NPR's view is along the lines that, well, the filter's already there, and we like the way it sounds, so we keep using it.