mgsouth

I've no experience with Synology and have no opinion regarding their motivations, execution, or handling of customers.

However...

Long long ago I worked for a major NAS vendor. We had customers with huge NAS farms [1] and extremely valuable data. We were, I imagine, very exposed from a reputation or even legal standpoint. Drive testing and certification was A Very Big Deal. Our test suites frequently found fatal firmware bugs, and we had to very closely track the fw versions in customer installations. From a purely technical viewpoint there's no way we wanted customers to bring their own drives.

[1] Some monster servers had tripple-digit GBs of storage, or even a TB! (#getoffmylawn)

One man's ongoing journey coaxing an LLM to write Common Lisp code. Bonus "AI generated" poem by Stanislaw Lem, and a five-paragraph story actually generated by LLM: "The Unspeakable Syntax: A Tale of Lispian Horror." [3] Suprisingly entertaining.

Posts so far:

[1] https://funcall.blogspot.com/2025/03/vibe-coding-in-common-l...

[2] https://funcall.blogspot.com/2025/03/vibe-coding-in-common-l...

[3] https://funcall.blogspot.com/2025/03/ai-silliness.html

[4] https://funcall.blogspot.com/2025/03/vibed-into-non-function...

    > I think a new approach might be to ignore the specifics of the old system, implement a new system

1. This is an old IBM COBOL system. That means EBCDIC, not UTF or even ASCII.

1.A Fine, we'll mass-convert all the old data from EBCDIC to UTF. Done.

1.A.1 Which EBCDIC character set? There are multiple variants. Often based on nationality. Which ones are in use? Can you depend on all records in a dataset using the same one (hint: no.) Can you depend on all fields in a particular record using the same one? (hint: no.) Can you depend on all records using the same one for a particular field? (hint...) Can you depend on any sane method for figuring out what a particular field in a particular record in a particular dataset is using? Nope nope nope.

1.A.2 Looking at program A, you find it reads data from source B and merges it with source C. Source B, once upon a time, was from a region with lots of French names, and used code page 279 ('94 French). Except for those using 274 (old Belgium). And one really ancient set of data with what appears to be a custom code set only used by two parishes. Program A muddles through well enough to match up names with C, at least well enough for programs D, E, and F.

1.A.3 But it's not good enough for program G (when handling the Wednesday set of batches). G has to cross-reference the broken output from A with H to figure out what's what.

1.B You have now changed the output. It works for D and F, but now E is broken, and all the adhoc, painstakingly hand-crafted workarounds in G are completely clueless.

1.C Oh, and there's consumer J that wasn't properly documented, you don't know exists, and handles renewals for 60-70 year old pensioners who will be very vocal when their licenses are bungled.

2. Speaking of birth years, here's a mishmash of 2-, 4-, and even 3-digit years....

As another layman, no, I don't think so.

The "twin paradox" [1] is a prime example. The two twins depart from a common point in time and space, go about their separate travels, and meet again at a common point in space-time. Despite both twins always having the same constant speed of light, one of the twins takes a shorter path through time to get to the meeting point--one twin aged less than the other. In the paradox case, the shorter/longer paths are due to differences in acceleration. But the same thing happens due to differences in gravitation along two paths. (In fact, IIUC, acceleration and gravitational differences are the same thing.)

Just thinking about the math makes my head hurt, but it's apparent that two different photons can have taken very different journeys to reach us. For example, the universe was much denser in the dim past. Old, highly red-shifted photons have spent a lot of time slogging through higher gravitational fields. As a layman, that would suggest to me that, on average, time would have.. moved slower for them?... they would be even older than naive appearances suggest. I don't think the actual experts are naive, so that's been accounted for, or there's confounding factors. But I could also imagine that more chaotic differences, such as supernovas in denser galatic centers vs. the suburbs, or from galaxies embedded in huge filaments, could be hard to calculate.

[1] https://en.wikipedia.org/wiki/Twin_paradox

You don't really want an agile toilet interface. This is more a waterfall project.

OK, the "typically 10^12 TEC" vs. a +/- 1 TECU (10^16 TEC) disturbance was really bugging me. I think the slide has an error, or there's an apples/oranges issue. The +/- 1 TECU looks to be consistent, but the typical background level is "a few TECU to several hundred" [1]. A Wikipedia page has shows the levels over the US being between 10 - 50 TECU on 2023-11-24, and says that "very small disturbances of 0.1 - 0.5 TEC units" are "primarily generated by gravity waves propagating upward from lower atmosphere." [2].

[1] https://www.swpc.noaa.gov/phenomena/total-electron-content

[2] https://en.wikipedia.org/wiki/Total_electron_content

Pretty astounding, isn't it? I don't see a paper, but there was a webinar [1]. There's a technical synopsis at 8:00. The phenomenon they're measuring is actually signficant. It's the total number of (free?) electrons between the satellite and the receiver. Typically its about 10^12 electrons/m^3 (@8:00 in video). The disturbance from the 2011 earthquake and tsunami was, if I'm reading the movie/chart correctly, about +/- 1 TECU, which is 10^16 electrons/m^3 (@10:40). The water elevation may only be a few feet in open ocean, but it's over a vast area. That's a lot of power.

They're measuring it by looking for phase differences in the received L-band (~2GHz) signals, rather than amplitude. That eliminates lots of noise. And they're looking for a particular pattern, which lets you get way below the noise floor. For example, the signal strength of the GNSS (GPS) signal itself might be -125 dBm, while the noise level is -110 dBm [2]. That means the signal is 10^-12 _milliwatts_, and the noise is about 30 times larger. But by looking for a pattern the receiver gets a 43 dB processing boost, putting the effective signal well above the noise.

[1] https://www.youtube.com/watch?v=BEpZmRPPWFo

[2] https://www.nxp.com/docs/en/brochure/75016740.pdf

The red line is axial acceleration. The rocket rapidly slows to terminal velocity, reaching it at about 25 sec., then continues to slowly decelerate as t.v. decreases as the air gets thicker. [edit: *] The black line is estimated velocity, as integration of the acceleration. It gives up trying to calculate that at about 45 sec. Based on the barometer readings, it looks like it was going about 650 fps at impact.

What I find interesting is the 4-second delay before igniting the second stage. This is very inefficient compared to immediately igniting it when the first stage burns out. Max-Q (airspeed pressure) issues? 30,000 ft permit ceiling?

Edit: * At 25 sec. it's still going up, so the velocity is decreasing due mainly to gravity, but the rocket is ballistic so the accelerometer is slightly negative due to air friction adding to the gravity deceleration. At about 40 sec. it has reached max altitude and velocity is zero. Accelerometer is still close to zero. Velocity picks up, as shown by barometric altitude curve. Eyeballing it, at about 65 sec. its reached terminal velocity, as shown by barometer curve being pretty flat. Decrease after that is due to decreasing t.v.

[This is a link to a Mastodon infosec topic. I've completely editorialized the page title, so am posting as Tell HN instead.] [Edit: Well, I submitted it that way. HN stripped the "Tell HN:". The original page's title is pretty useless, so don't know what the proper thing to do is.]

EXT (all versions) has a filesystem flag telling the kernel to panic on FS error. In the link, Will Dormann demonstrates inserting a USB key with a malicous image and instantly rebooting the PC.

In this case, the laptop had USB auto-mounting enabled. However, I believe this should apply to any mounts against user-modifiable or -specifiable sources. NFS, FUSE, user namespaces, even local files with "-o loop" option. And the MOUNT(8) man page has this interesting tidbit:

    Since util-linux 2.35, mount does not exit when user permissions are
    inadequate according to libmount’s internal security rules. Instead, it
    drops suid permissions and continues as regular non-root user. This
    behavior supports use-cases where root permissions are not necessary
    (e.g., fuse filesystems, user namespaces, etc).

For folks jumping on saying "that's not a carrier thing". All comms are a carrier thing. Whether it's ETWS, SMS, or IP, it's going through the carrier, they process it, and they do extensive traffic management. Carriers absolutely can and will inspect, proxy, aggregate, and do anything else that will tease out another few % of "free" capacity.

[Edit:] All too real scenario: Carrier knows about particular IP addresses and ports used by alert service. Carrier makes provision for separate path for it. Carrier also tries to shave said provisioning to the bone, calculates a worst-case, and adds 5% capacity. Which doesn't get updated when that particular app gets a 6% boost in subscriptions. Back in the old days the traffic management folks would be on top if it, but that's all been outsourced...

It varies, a lot, and depends upon a lot of things. I'm not current on all the current details, but many moons ago was involved in push notification development.

* Notification path. IoS at the time was pretty protective of the user's battery, and had specific services you had to use. I imagine there's special treatment now for emergency communications.

* Phone state. How deeply asleep is it? Are there other background apps frequently contacting the mothership? Multiple apps can get their requests batched together, so as to minimize phone wake-ups. You can also benefit from greedy apps--VoIP apps, for example, might be allowed/figured out a hack to allow frequent check-ins, and the other apps might see a latency benefit.

* Garbage carriers. Hopefully emergency alerts have a separate path, but I've noticed my provider (who shall remain nameless but is a three-letter acronym with an ampersand in the middle) sometimes delays SMS messages by tens of minutes. (TBF, in my case there might also be a phone problem [Android], but since nameless provider forced it on me when they went 4G-only they're still getting the blame.)

In your case, my money would be on the carrier. Pushing a notification to all phones in an area can be taxing, and cheaping out on infrastructure is very much a thing.

For docs, your best bet would be to go to the developer sites and pull up the "thou shalt..." rules, particularly regarding network activity, push notification, and permitted background activities. And yeah, Apple was much more dictatorial, for good reasons.

You can test ESR in-circuit, with caveats. Here's a good thread from EEVblog [1].

[1] https://www.eevblog.com/forum/beginners/is-there-any-way-to-...

Totally believable if the debugging device was doing something with a serial port. I once hacked something together to interface a PC serial port to a Raspberry Pi. The PC serial is real-ish RS-232, with negative voltages. The Pi side was just 0/3.3V positive. I had a nice 18-volt power brick laying around, and just split it's output down the middle--what was 0 volt ground was used as -9 volts, the middle voltage was now 0 volt ground, and the 18-v line was now +9 V.

At first everything seemed OK. but when I plugged a monitor into the PI I Was Made To Realize a) the nice 18-volt PS really was high quality, and although it was transformer-isolated its output ground was tied to the wall socket earth, b) monitors also tie HDMI cable ground to earth, and so c) my lash-up now had dueling grounds that were 9V apart.

My most vivid gRPC experience is from 10 years or so ago, so things have probably changed. We were heavily Go and micro-services. Switched from, IIRC, protobuf over HTTP, to gRPC "as it was meant to be used." Ran into a weird, flaky bug--after a while we'd start getting transaction timeouts. Most stuff would get through, but errors would build and eventually choke everything.

I finally figured out it was a problem with specific pairs of servers. Server A could talk to C, and D, but would timeout talking to B. The gRPC call just... wouldn't.

One good thing is you do have the source to everything. After much digging through amazingly opaque code, it became clear there was a problem with a feature we didn't even need. If there are multiple sub-channels between servers A and B. gRPC will bundle them into one connection. It also provides protocol-level in-flight flow limits, both for individual sub-channels and the combined A-B bundle. It does it by using "credits". Every time a message is sent from A to B it decrements the available credit limit for the sub-channel, and decrements another limit for the bundle as a whole. When the message is processed by the recipient process then the credit is added back to the sub-channel and bundle limits. Out of credits? Then you'll have to wait.

The problem was that failed transactions were not credited back. Failures included processing time-outs. With time-outs the sub-channel would be terminated, so that wasn't a problem. The issue was with the bundle. The protocol spec was (is?) silent as to who owned the credits for the bundle, and who was responsible for crediting them back in failure cases. The gRPC code for Go, at the time, didn't seem to have been written or maintained by Google's most-experienced team (an intern, maybe?), and this was simply dropped. The result was the bundle got clogged, and A and B couldn't talk. Comm-level backpressure wasn't doing us any good (we needed full app-level), so for several years we'd just patch new Go libraries and disable it.

One does not simply walk into RPC country. Communication modes are architectual decisions, and they flavor everything. There's as much difference between IPC and RPC as there is between popping open a chat window to ask a question, and writing a letter on paper and mailing it. In both cases you can pretend they're equivalent, and it will work after a fashion, but your local communication will be vastly more inefficient and bogged down in minutia, and your remote comms will be plagued with odd and hard-to-diagnose bottlenecks and failures.

Some generalities:

Function call: The developer just calls it. Blocks until completion, errors are due to bad parameters or a resource availability problem. They are handled with exceptions or return-code checks. Tests are also simple function calls. Operationally everything is, to borrow a phrase from aviation regarding non-retractable landing gear, "down and welded".

IPC: Architectually, and as a developer, you start worrying about your function as a resource. Is the IPC recipient running? It's possible it's not; that's probably treated as fatal and your code just returns an error to its caller. You're more likely to have a m:n pairing between caller and callee instances, so requests will go into a queue. Your code may still block, but with a timeout, which will be a fatal error. Or you might treat it as a co-routine, with the extra headaches of deferred errors. You probably won't do retries. Testing has some more headaches, with IPC resource initialization and tear-down. You'll have to test queue failures. Operations is also a bit more involved, with an additional resource that needs to be baby-sat, and co-ordinated with multiple consumers.

RPC: IPC headaches, but now you need to worry about lost messages, and messages processed but the acknowledgements were lost. Temporary failures need to be faced and re-tried. You will need to think in terms of "best effort", and continually make decisions about how that is managed. You'll be dealing with issues such as at-least-once delivery vs. at-most-once. Consistency issues will need to be addressed much more than with IPC, and they will be thornier problems. Resource availability awareness will seep into everything; application-level back-pressure measures _should_ be built-in. Treating RPC as simple blocking calls will be a continual temptation; if you or less-enlightened team members subcumb then you'll have all kinds of flaky issues. Emergent, system-wide behavior will rear its ugly head, and it will involve counter-intuitive interactions (such as bigger buffers reducing throughput). Testing now involves three non-trivial parts--your code, the called code, and the communications mechanisms. Operations gets to play with all kinds of fun toys to deploy, monitor, and balance usage.

Ooh, clever. Vaguely envision entropy problems, that some mash-up of Godel's Incompleteness theorem, Maxwell's Demon, and Bell's Inequality, and Newton's laws conspires against it. Maybe sending changes back add entropy, or moves it around? Would make a good old-school SF story, with backwater multi-verse dumps for waste entropy, a free-lance troubleshooter uncovering a secret corporate scandal regarding deleterious effects, etc.

No. This and all previous flights have intentionlly been barely sub-orbital, with less than one orbit. Launch in Texas, re-entry over Indian Ocean. A full orbit at that altitude takes about 90 minutes; this was over in a little over an hour.

The reason was safety. If it was orbital, then controlling the re-entry would require a sucessful relight of the engines. If that failed then the re-entry point would depend upon the vagaries of orbital decay from residual atmospheric drag. That's no doubt why today's relight was so brief; they didn't want to significantly alter the reentry point.

Two weeks ago [edit: local time] we submitted a request for some enhancements we really need for our term final paper, but haven't heard anything. We realize this is a volunteer project, but our whole final grade hinges on this, so we're going to try submitting the requests earlier...

* Can we have a multi-verse?

* We really need to be able to kill a variable but have it linger on for a while. This is to allow revenge, and...

* Our whole paper is about Bob/Alice going back in time, shooting his/her grandfather, who lingers long enough to sire their father's brother Tom, who marries their mother instead, who gives birth to Alice/Bob, who although now their own cousin is still a murderous beast, goes back in time and shoots at their grandfather, misses, kills Tom instead, thus their original father marries their mother, and Bob/Alice is born. Thus demonstrating local paradoxes with meta-consistency and explaining much in our current timeline. We're gonna get an A+ for sure.

* We suggest storing the metaverse as a directed cyclic graph of the operations and not saving state. To collapse the metaverse (in the quantum physics sense, not in emiT's oh-no-everything-is-impossible sense) simply apply the graph to a set of pre-conditions, and as you process each node apply its state constraints to the metaverse state. Handling the node cycles is normally seen as a challenge, but there's some sample code posted on HN in March, 2028 that should make it a breeze.

I don't think so. That's assuming the program will always be in a frame of reference which is temporally unbounded. If, for example, it fell into a black hole it would, IIUC, never progress (even locally) beyond the moment of intercepting the event horizon.

Nope on the last one:) That's from Adventure.

Works a treat :)

As TFA says, they were specifically looking for the effect. It an "HDAC inhibitor." These uh, inhibit the enzyme HDAC, which is known to shut down brain plasticity in adult (mice). As to why they figured that out, some of the studies cited in TFA were looking at brain plasticity, plaques, brain damage (strokes?) and (of course) Alzheimer's.

BTW, one of Sodium Valproate's trade names is Depakote. Very commonly prescribed (or at least used to be) for treatment of bipolar disorder and epilepsy.

OK, one more round. An API spec is a contract, not a guarentee of correctness. You, as the client, are free to pass me any data that fits the spec. If my parsing library does the wrong thing, then I've got a bug and need to fix it. My tests are also defective and need to be adjusted.

If you passed 3.974737373 to cos(x), and got back 200.0, would you be mollified if the developers told you "that value clearly isn't in the unit test cases, so you're in undefined behavior"? Of course not. The spec might be "x is a single-float by value, 0.0 <= x < 2.0 * PI, result is the cosine of X as a single-float." That's a contract, an intent--an API.

The same for a mail parser. If my library croaks with a valid (per RFC) address then I've got a problem. If I try to provide some long, custom, set of cases I will or won't support, then my customer developers are going to be rightfully annoyed. What are they supposed to do when they get a valid but unsupported address? Note we're not talking about carving out broad exceptions reasonable in context ("RFC 5322 except we don't support raw IP addresses foo@[1.2.3.4]", "we treat all usernames as case-insensitive"). And we're not talking about "Our spec (intent) is foo, but we've only tested blah blah blah."

Early in my career I would get pretty frustrated by users who were not concerned with arranging their data and procedures the right way, clueless about what they really were doing. OK, so I still get frustrated by stupid :) But it's gradually seeped into my head that what matters is the user's intentions. Specs are an imperfect simplificaton of those very complex things, APIs are imperfect simplifcations of the specs, and our beautiful code and distributed clusters and redundant networks are extremely limited and imperfect implementations of the APIs. Some especially harmful potential flaws get extra attention during arch, implementation, and testing. When things get too far out we fix them.

We've been there, done that. CRUD apps on mainframes and minis had incredibly powerful and productive languages and frameworks (Quick, Quiz, QTP: you're remembered and missed.) Problem is, they were TUI (terminal UI), isolated, and extremely focused; i.e. limited. They functioned, but would be like straight-jackets to modern users.

(Speaking of... has anyone done a 80x24 TUI client for HN? That would be interesting to play with.)

We're in general agreement about the purpose of unit tests. I disagree on a couple of points.

Tests do not document the API. No test is complete, and for that reason alone can't completely document anything. For example, a good API might specify that "the sender must be non-null, and must be valid per RFC blah." There's no way to test that inclusively, to check all possible inputs. You can't use the test cases to deduce "we must meet RFC blah." You might suspect it, but you'd be risking undefined behavior it you stray from input that doesn't exactly match the test cases. And before anyone objects "the API docs can be incomplete too," well, that true. But the point is that a written API has vastly more descriptive power than a set of test cases. (The same applies to "self-documenting code". Bah humbug.) There's also the objection "but you can't guarentee cases you don't test!" Also true. That's reality. _You can never test all your intended behavior._ You pick your test cases to do the best you can, and change your cases as problems pop up.

The other thing I would shy away from is including throwaway tests in the framework. Throwaways are a thing, developers use them all the time, but don't make them unwanted stepchildren--poorly (incompletely?) designed, slapped together, limited scope, confusing for another developer (including time-traveling self) to wade through and decide whether this is a real failure or just bogus test. They're tech debt. Less frequently used tests are another matter. For example, release-engineering tests that only get run against release candidates. But these should be just as much real, set in stone, as any other deliverable.

Which I guess is a third viewpoint nuance difference. I treat tests as being part of the package just as much as any other deliverable. They morph and shift as APIs change, or dependencies mutate, or bugs are found. They aren't something that can be put to the side and left to vegetate.

Excellent points, violently agree, my question was poorly worded. The purpose of units tests is to verify the contracted API is actually being provided by the implementation details. A clearer question might have been "what are unit tests for if not to exercise the implementation details, verifying they adhere to the API?" Unit tests validate implementation details, integration tests validate APIs.

To me, a good unit test beats the stuffing out of the unit. It's as much a part of the unit as the public functions, so should take full advantage of internal details (keeping test fragility in mind); of course that implies the unit test needs ongoing maintenance just as much as the public functions. If you're passing a small set of inputs and checking the outputs, well that's a smoke test, not a unit test.

To answer your last question, I want the alarm bells to ring whenever the implementation details don't hold up. That's whether the function code changed, a code or state dependency changed, or the testing process itself changed. If at all feasible all the unit tests run every time the the complete suite is run, in full meat-grinder mode. "Complete suite" is hand-wavy; e.g. it might be the suite for a major library, but not the end-to-end application.

What do you use unit tests for, other than verifying implementation details?

Perhaps we have a difference in definition. To me, a unit test for a function such as "parse_news_email" would explore variations in parameters and states. Because of combinatorial explosion, that often means at least some white-box testing. I'm not going to generate random subjects and senders, and received-froms, I'm going to target based on internal details. Are we doing smart things with the message ID hostname? Then what happens if two messages come in with the same message ID but from different relays? The objective is that the unit test wrings out the implementation details, and the caller's unit test doesn't need to exhaustively test them.

This white-box texting may require directly poking at or mocking internal functions or at least abusing how they're called. For example, parsing the news item might entail pulling up and modifying conversation thread cache entries or state. For some of the tests you may need hand-crafted cache state, it's not feasible to create unique states for each parameter combination you're testing, and testing a combination will pollute the state for the following combinations. Or maybe the function depends upon an external resource you can't beat to death with a million identical requests. So the least-bad, simplest solution may be to freeze or back out part of the normal state update in the unit test. Which would usually involve directly invoking the internal routines.

Can this lead to fragile, false-positve to the point of useless tests? You betcha. That's where entertaining two contrary viewpoints is needed :) Use experience and good judgement about pros and cons in the particular situation.

IANAChemist, but to extend the cheesy analogies chemical bonds are like joint custody in a divorce; two atoms share one or more electrons. If it's split more or less evenly then it's called a covalent bond. If it's stacked in one atom's favor then it's called ionic. If it's kind of in a gray area in the middle then its called a polar covalent bond. [1]

Adhesion, even due to electrostatic or van Der Waal's forces, doesn't cause an electron to be shared [2].

To switch up the analogy (again, IANAC): as I understand it chemical bonds are like a couples thing; if you invite one you have to invite the other, and if you are interested in replacing a chemical bond with one of the atoms you need to first tear the couple apart. That's because chemical bonds share an electron; to share a particular electron with a new atom you need to stop sharing with the first one. (Sort of. I believe it's a lot more complicated than that, with group marriages and such.)

Adhesion is more like a friendship thing. You might hang out together, but there's no intimiate involvement. The electronic bonds are still available, so each each substance can do its normal chemical reaction thing with other atoms.

[1] https://en.wikipedia.org/wiki/Ionic_bonding

[2] Despite my previous cheesy analogy, electrostatic adhesion is the real static-cling force, not van Der Waal's. (But electrostatic adhesion isn't what makes sticky tape sticky, van Der Waals is.) The former is between entire molecules or groups of molecules, one group having a total positive charge compared to the other. van Der Waal's is pin-point attraction between local differences in molecular charge distribution, and each molecule in total might be electrically neutral. For example, a neutral water molecule has two highly-positive areas near the Hydrogen atoms and a highly-negative region away from them.

For pressure-sensitive-adhesive tape (cellophane tape) it's mainly fuzzy static cling--wetting and van Der Waal's forces [1]. Wetting is when two substances (even solids) intermingle at their interface. van Der Waal's force is when a negatively-charged area of one molecule lines up the a postively-charged area of another.

[1] https://science.howstuffworks.com/innovation/everyday-innova...

USPS - United States Postal Service (the governmental mail delivery organization). Not to be confused with:

- UPS, United Parcel Service (a for-profit; USPS is notoriously not-for-profit).

- UPS, Uninterruptable Power Supply

APC - Armored Personell Carrier -- military vechicle for transporting troops. Not to be confused with:

- APC, Formerly American Power Conversion Company, now an initials-only brand of some conglomerate, who coincidently make UPS units (the electronic device, not the delivery drivers).