renehsz

The binary is still 16-bit NE, but will run just fine on 32-bit Windows where NTVDM is built-in, and on 64-bit Windows after installing OTVDM.

Electron needs to die.

But it's convenient. I can't really fault people for using it.

Yeah, most people own a TV but would be better off without it.

> 18 gigawatts of heat a day

Gigawatts per day is nonsense in this context. It's a small but telling mistake. If they can't even get their units right, that speaks a lot about the trustworthiness (or lack thereof) of this article.

Also I can't speak for others, but to me the amount of energy a nuclear bomb releases is not very relatable. But as it turns out, it's not even that much. A typical nuclear reactor unit easily releases more than a Hiroshima bomb worth of heat a day. A bomb is devastating because all its energy gets released over a fraction of a second, not because of its amount of energy in absolute terms.

The sad part is that there there may be a real story here, but it drowns in the meaningless bomb analogy. They could've written a real informational piece about the environmental impact of data centers. Instead, they chose to craft a sensationalist story that not only fails to enhance people's understanding, but might actively mislead them into thinking data centers are nuking the neighborhood.

Are the pelicans still a useful benchmark at all?

I would guess that

1) they're probably in the training data, and

2) models have gotten too good at this task to compare them meaningfully (I tried doing a blind test and couldn't reliably tell 6.1 Astra, Sol, and Terra apart at reasoning levels that approximately match in cost)

I'm not a pilot, so take everything I say with a grain of salt.

Yes, a mistake can lead to a go-around, which at a busy airport can easily add an extra 10 to 20 minutes of flight time. But as long as no such mistake is made, a hand-flown visual approach can actually be quite a lot faster.

But first, we have to clarify the terminology. On most instrument approaches, the autopilot only flies the beginning of the approach, until the pilot flying decides to disconnect and lands the plane manually (somewhere between the final approach fix and minimums, depends on visibility and crew preference). So the most common way of flying an approach is neither fully automated nor fully manual.

Autolands are only done rarely, like in low visibility or periodically for pilots and aircraft to stay current. Visual approaches, on the other hand, are more common (though it depends on the region, controllers in the US hand out more visual approach clearances than controllers in Europe for instance). But even on a visual approach, crews often keep the autopilot engaged until very late in the approach or at least use the ILS as an aid while flying manually. That makes it tricky to do a comparison.

All external conditions being equal, I'd assume that an autoland is indeed less likely to lead to a go-around than a hand-flown visual approach. This is mainly because autolands, like other instrument approaches, are typically set up with a long final and earlier stable gate (typically 1000ft). A lot of go-arounds happen due to being unstable at the gate (too high, too fast, not configured, etc.) - that's less likely with an autoland which forces you to be stable much further out. Additionally, an autoland has a very low decision height leading to fewer go-arounds in marginal weather (though in such cases a visual approach most likely wouldn't be attempted in the first place). On the other hand, an autoland has stricter crosswind and maybe also tailwind limits, could be subject to ILS signal interference, and usually requires two or three autopilots to be fully functional. Still, the first argument has more weight to it I think.

But assuming no go-around, a hand-flown visual approach can be quite a lot faster than an autoland! As I already mentioned, autolands need a long final to establish early to give the airplane time to stabilize (often crews are looking to establish well prior to the FAF). A visual approach, on the other hand, allows tight turns onto final, slowing down and configuring the airplane much later, etc. The aircraft needs to be stable at the gate, but when flying visually that's typically 500ft AGL, so short final basically. Visual approaches also give controllers more freedom to give vectors with fewer track miles, and visual separation allows for reduced spacing.

Overall, I think that hand-flown visual approaches often save time compared to autolands, and possibly over other instrument approaches as well. And even if the probability of a go-around is slightly higher (assuming equal weather conditions), a go-around is still so rare that despite being a significant outlier in flight time, I wouldn't think it moves the average up much.

But maybe the comparison just doesn't make much sense to begin with. An airplane is flown by pilots and computer systems together. Pilots can choose between different levels of automation, but both extremes of the automation spectrum (on the one hand: fully hand-flown visual approaches without even the ILS frequency or any navaids tuned in; on the other hand: full CAT III autoland) are quite rare for airliners. Most approaches fall somewhere in the middle on that automation spectrum. Is that the safest and quickest way to do it? I don't know. But I assume the industry has converged on it for good reasons.

Your claim was that "the autopilot does almost all the critical work", and that couldn't be further from the truth in any airliners you can buy today.

I didn't say that an autonomous airliner could never be built. With more technological progress it might become feasible at some point despite the immense complexity.

To anyone who hasn't already: I really recommend checking out Haiku OS [1], the FOSS successor to BeOS. It's so pleasant to use and supports a surprisingly large catalog of software.

[1]: https://www.haiku-os.org/

Exactly! Don't lock yourself in to a single provider, especially for email where it's fairly easy to avoid by using your own domain.

This take is so ignorant and provably false. I can't tell if you're trying to ragebait or if you actually believe this.

The autopilot does not do "almost all critical work", not even close. It only does some of the routine work (definitely not all of it). But the real critical work is when stuff goes wrong, dealing with emergencies.

The inherent complexity of aviation means that there are so many different failure modes and combinations thereof that no traditional system could ever handle all possibilities and edge cases.

I'm not going to claim that an AI could never do it. But as of right now, with current technology, well-trained pilots are absolutely critical to safety in even the most advanced airliners.

Also, the survivorship bias argument runs against you. Most events where pilots save the day are completely invisible. Like catching an incorrect clearance, a misconfigured approach, dealing with a technical malfunction, etc.

And even when disasters happen, it is very rare that simply engaging the autopilot would have saved the day. In fact, there are plenty of examples where the opposite is the case, and dropping to a lower level of automation would, in hindsight, have been better.

Guys, let's not turn everything into a trains vs cars debate. Obviously, trains are much safer.

But the argument that the relative risk of trains is far lower is, unfortunately, often used as an excuse to not take safety in absolute terms seriously. It's almost like saying: "Because trains are already so much safer than cars, the few crashes that still happen are just bound to happen, they're a fact of life we have to accept, and not worth doing anything about." (I am exaggerating, of course.)

But many of these accidents are in fact easy to prevent, even without huge investment in new infrastructure. So we should prioritize that and make our voices heard that we care about railway safety! And no, this is not a psyop to make people drive their cars more, that would be ridiculous.

Let's not jump to conclusions. Funding rail infrastructure is important, but it's not clear at all whether that would have helped prevent this accident. Malfunctions can happen even in the most advanced newly-built systems. Often the overall safety level depends more on how you deal with degraded states than how the system performs in its fully functional state.

LZB does cab-signalling and continuously supervises speed and braking curves. Combined with AFB it can accelerate and brake automatically to LZB targets. So regular operations are already partly automated (and have been for a long time). The system already doesn't rely on perfect driver attentiveness for safety. The driver should still watch the track ahead, but trains usually can't stop within line of sight anyway, so for separation we have to rely on the signalling system.

Drivers are absolutely still needed for other parts of the operation though, like working stations, shunting, and perhaps most importantly handling irregularities. Faults can happen and you don't want the train to be stuck out on the track for hours. Instead, it makes so much more sense to either fall back to lineside signals (often accompanied with a point-based train protection system) or driving within line of sight.

FBI open up

There is no doubt whatsoever that trains are far safer than cars. But often that fact is used as an excuse to not invest in safety. "We don't need to do anything to make thing X safer, because look at that other thing Y that people do which is way more dangerous." (I assume you didn't mean it that way, but some people really do make this argument.)

Human lives matter in absolute numbers, and we should strive to increase safety wherever possible with reasonable effort. Railways in some countries still have some very low-hanging fruit!

The aviation industry has shown that safety as the number one priority does not have to be prohibitively expensive. Layers of redundancy, excellent training, and very good investigations and changes based on their recommendations are what keeps the flying public safe.

Accidents still happen in aviation, but we're at a point of diminishing returns where increasing safety is getting quite difficult. When an aircrew encounters a problem, they can't just stop the plane mid-air to figure things out. The plane has to land, no matter what. That is inherently more risky.

Contrast that with a train, which can more or less just stop wherever it is when something goes wrong. This allows for building a lot of fail-safe/passively safe systems. When there's a problem, just halt operations and take your time to figure things out. Good procedures and adherence to them are still absolutely necessary, but at least there's usually no actual time pressure (only perceived) and malfunctions rarely pose an actual risk if handled correctly.

What aviation has also shown us is that accident investigations need to be 100% honest about underlying causes. "This guy made a mistake, too bad" is never ever an acceptable reason. We have to dig deeper.

People will always make mistakes. But how was such a simple mistake allowed to have such dire consequences? Were there not enough layers of redundancy? Was the training inadequate? Were the rules and procedures inadequate, underspecified, or unclear? Was there a company culture of bending the rules to get the job done? Was there a general lack of safety culture and incident management? Etc.pp.

> All the rules you spoke of by the way were already in-place

I had guessed that was the case, but didn't want to state it definitively, as I'm not familiar with the rules in Spain specifically. But that then raises the question of why the rules weren't followed.

> the rail operator instructed to continue at normal speed. When the train driver asked 'at normal speed?' the operator confirmed

As I explained earlier, "there's been a misunderstanding" is not good enough, I'm sure the report will dig deep to find the underlying causes and will issue plenty of recommendations to prevent this in the future.

I will refrain from speculating on what those causes are though, as there are far too many possibilities. But it's almost certainly a combination of multiple unfortunate factors that led to this horrible accident.

> This is in the way more like the Washington D.C. helicopter plane mid-air where some normalization of deviance got people to ignore automated protection systems.

I think that's not quite accurate. Yes, there was a normalization of deviance. But it wasn't primarily that automated protection systems were ignored.

First, the systems on board both aircraft could not have saved them. TCAS resolution advisories are inhibited below 900ft AGL and aural traffic advisories are inhibited below 400ft AGL. The aircraft collided below that altitude. The system wasn't ignored, it just doesn't do much at low altitude. The RJ crew got a TA about 20s prior to the crash, but that's not something that would normally require evasive action (they're trained to act immediately on an RA, not a TA). They were set up for landing. It's hard to find any fault with them.

The RJ wasn't equipped with ADS-B In, and the helo's ADS-B Out was misconfigured since installation. ADS-B In could have alerted both crews almost a minute prior to impact. But it wasn't available.

Second, if you're referring to the tower: Yes, the controller did get an automated conflict alert, but he did not ignore it. He asked PAT-25 whether they had the RJ in sight and told them to pass behind it. This response wasn't good enough, but that's mainly attributed to the controller's high workload and time pressure leading to omissions.

A proper traffic advisory should have included azimuth, distance, direction of travel, and type and altitude of the conflicting aircraft, e.g.:

PAT-25, traffic ten o'clock, one mile, north-west bound, a CRJ descending through four hundred, circling approach to runway 33.

A proper safety alert should also include an action to resolve the situation, e.g.:

Traffic alert, PAT-25, traffic ten o'clock, one mile, a CRJ on final for runway 33. Advise you [descend/turn] immediately.

Either one might have prevented the accident. But when ATC gets busy, the reality of those calls often looks quite different than how they're described in a textbook. Combining local and helicopter control with 12 aircraft on frequency is just too much. Of course, that leads to routine conflict alerts (5 separate events in the 18 minutes leading up to the crash). Sure, nuisance alerts lead to desensitization (and the report discusses that), but here the workload seems to have been the bigger underlying factor.

Of course, this is far from the only contributing factor. The normalization of deviance that the NTSB actually found are that visual separation had become the primary way of separating helicopters from aircraft, helicopter crews reporting "in sight" when they hadn't positively identified the traffic yet, the tower trying to "make it work" rather than forcibly slowing operations down, etc.

That in addition to putting a helicopter route as little as 75ft below the approach path, the helicopter's altimeter being 100ft off (within spec!), the helicopter crew's use of night vision gogggles severely limiting field of view, helicopters and fixed-wing aircraft being on separate frequencies severely limiting the RJ crew's SA.

And perhaps most egregiously, the FAA ignoring the countless warning signs (15 thousand close proximity events over 3 years, are you kidding me?) Failing to fix the helo route, failing to reduce arrival rate (the request from Potomac TRACON wasn't forwarded due to being "too political"), failing to improve the tower's conflict alert software... People did not ignore automation, the regulators ignored lots of growing holes in the slices of Swiss cheese.

Cab-signalling train protection systems like LZB (and more modern alternatives like ETCS) are generally considered to be sufficient to ensure safe separation. The interlocking only allows setting a route if all its sections are detected vacant, conflicting routes are locked out, and flanks are protected. Meanwhile, the train protection system prevents trains from exceeding their movement authority. These systems can even largely monitor themselves and are designed to be fail-safe (often by putting all signals on danger and letting the operators figure it out).

But in those cases where the system does crash and reset, how can operations be started again? That's where you need well-specified fallback procedures. One such procedure might be that, in case axle counter sections to lose their counts (because of a crash of the interlocking or the axle count evaluator), causing affected sections to show as disturbed and mandating a manual reset, each section must be swept by a train running on sight (under a caution order in LZB or OS mode in ETCS).

Tell that to the dozens of families who lost loved ones today! At least 68 people (and still counting) lost their lives. Ambitious, loving, caring human beings, who died completely unnecessarily! No excuse is good enough to justify that.

This type of accident is particularly unacceptable because it's so preventable! I'm not going to speculate on the causes before the official report is out. But a collision between two trains is not that hard to prevent with a train protection system. And if that system (or a component of it) crashes (or malfunctions in a fail-safe way), but operations should still continue, then there need to be safe fallback protocols in place that everyone is trained to follow.

One such rule might be, for instance, that following an electronic interlocking failure causing axle counter sections to be reset, meaning track vacancy cannot be proven, track sections must be swept by trains that may only run on sight at ~40km/h max.

"Someone made a mistake" is never an acceptable excuse. That's what we had to learn in aviation a long time ago. Nobody goes to work wanting to cause a fatal accident. The train dispatcher(s), driver(s), and whoever else might have been involved in this, (most likely) did not intend to cause this. But it is almost always a combination of bad procedures, normalization of deviance, lack of safety culture, bad training, lack of regulatory oversight, and of course inadequate technical equipment and safety systems, that together lead to fatal accidents.

Accidents like this one are fully preventable, there's no excuse, but that doesn't mean we should blame a particular person. Instead, it is the entire system, which is supposed to have multiple redundant layers of safety, that failed us. Investigators are going to come up with many recommendations to prevent similar accidents in the future. Let's hope (and make our voices heard) that these recommendations actually get implemented as well.

The security industry has a vested interest in spreading fear and panic. That's how they make money. But, to be fair, some of it may be necessary to motivate people to patch their stuff, so there could be good intentions behind it also.

In this specific situation, a lot of misery could have been prevented had the embargo not been broken. That's the crux of the issue: Chainguard's and Calif's incompetence and irresponsibility. Had the patch been out at disclosure, people could have updated quickly and wouldn't have had to choose between downtime and an unspecified risk of getting pwned.

There are only two types of people: Those who are security engineers, and those who pretend to be.

Yes, the cybersecurity industry definitely oversells itself on every (social media) channel it can find. But to be fair, it kind of has to. Many people and companies are notoriously lazy about secutity and patching until something goes wrong. So you have to cause a stir, oversell the risk, and create a sense of urgency, to get them to act.

Obviously, there are also some people in cybersecurity who oversell not for the greater good, but only to further their careers... and even those who are honest and would prefer not to self-promote like that, are sort of forced to, because visibility can matter as much (if not more than) expertise when trying to find a job in cybersecurity, as you'll look like an underachiever if you don't oversell yourself like everybody else.

Can you elaborate a bit on the use cases of HaLow?

https://GiveUpGithub.org - why and how to ditch GitHub.

> For the risk of shock from an electrified appliance, that’s what the ground is for

Ground does not protect against every shock hazard! Devices can fail in many ways where live parts are exposed without contacting the grounded casing. Also, imagine a little child poking a metal stick into the outlet. Now you'd better hope that outlet has GFCI. Modern code does not call for it in a child's bedroom, does it?

Edit: To be fair, modern receptacles should be tamper-resistant, but then imagine a child reaching into a lightbulb socket, or cutting through a wire, or the insulation on a wire becoming damaged, etc. pp.

> for all practical purposes you almost do have [GFCI] on every circuit

But there are still gaps! I got shocked by an old clothes iron once (and I'm glad it tripped the RCD at the panel). Bedrooms and living rooms can have electrical faults too!

Another advantage of RCD at the panel is that it protects all downstream parts of the panel and all circuit wiring too! A lot of fatalities come from people working on live wiring. (In fact, many electrocution deaths are electrical contractors.) Now sure, they almost certainly weren't following correct safety procedures, but still, a lot of them could have been saved by an RCD. Some people probably die changing their light bulbs. That's preventable by installing an RCD at the panel, so that the entire circuit is protected, not just everything plugged into a GFCI outlet.

> To me seems like people are hating on a pretty great system. [...] localized fault detection [...] would seem like an advancement

I agree that localized fault detection, all else being equal, is an advancement. But if it comes at the cost of no GFCI protection at all on other circuits, I'm not sure it's worth the tradeoff.

Hundreds of people in the US die every year from low voltage electrical shocks. This number used to be a lot higher before GFCI was common, but it likely could be lower still if GFCI was required everywhere.

Obviously it would be best to have broad coverage and localized tripping, but if I had to pick one, I'd choose broad coverage. Calling it "going backwards" misses the concern of how much is protected, rather than just how localized the impact is when there is a fault.

Three-phase power is really about delivering more power with less copper by 1) sharing the neutral conductor (or getting rid of it) and 2) using lower currents which can make do with much thinner conductors.

The difference between one three-phase feeder and three completely separate two-wire circuits is that the three phases, which are 120° apart, share a single neutral conductor. In fact, if the load is perfectly balanced across the phases and currents are sine waves, they will cancel each other out, so neutral will carry no current at all and can be omitted! But in practice, there still usually is a neutral conductor to carry the imbalance (except for specific loads like delta and star motors under certain conditions). In total, we only need 4 wires instead of 6 to carry the same amount of power. That's 1/3 less copper! (Excluding PE of course.)

Now, compared to using a single two-wire circuit rated for three times the current, three-phase also wins by a long shot. (We're again assuming a balanced load and equal power factors.) This is because resistive heat scales with the current squared, so 3 times the current produces 9 times the amount of heat at the same resistance. So, we need to use thicker conductors to lower the resistance. But the area of its cross-section grows quicker than the surface area to dissipate heat, so the maximum current a conductor can safely carry scales sublinearly with its cross-sectional area. For example, 1.5mm² will suffice under most conditions to carry 16A, but for 48A we'll typically need 10mm².

All in all, the rule of thumb is that three-phase AC gets you the same amount of power for roughly 25% less copper compared to single-phase AC!

Some loads also make use of the rotating magnetic field, like motors (see below).

Lastly, lower currents will reduce heating in case of loose connections, reducing the risk of fire. On the other hand, a 400V RMS phase-to-phase shock is a lot more severe than a 230V RMS phase-to-neutral (or phase-to-PE) shock.

Common use cases (load-side):

- Motors. Three phases produce a rotating magnetic field, perfect for simple self-starting motors. (Arguably, this is less relevant today with more modern motor designs, though three-phase induction motors are still widely used.)

- Electric cookers (usually split by cooking zones and oven, like one phase for two zones each, and the third phase for the oven)

- Water heaters (especially those that heat water instantaneously on demand)

- EV charging (even an ancient European three-phase installation is likely able to deliver 11kW of power and can therefore fully charge an EV overnight)

I can't talk about Japan, but in the European installations that I'm familiar with, all general-use circuits are also protected with RCD (GFCI).

> Curious why you’d need/want whole home gfi

Because the danger they protect against is not confined to bathrooms and the outdoors!

An RCD (GFCI) trips quickly when there is an imbalance between outgoing and returning current exceeding a certain threshold, indicating that some current is likely leaking to earth. A little more than 30mA AC through the body sustained for a couple of seconds can kill someone, but is not enough to trip a regular circuit breaker!

Wetness increases conductivity and therefore the risk of a dangerous electric shock, but a faulty appliance or damaged cable elsewhere exposing you to mains voltage can be life-threatening too!

So, why shouldn't we protect the entire house?

> I'm assuming [...] if there’s a short on any circuit power to the entire house is cut

Small nitpick: a GFCI/RCD doesn't trip because of a line-to-neutral short circuit, it only trips if some current "escapes" to somewhere else. Though it is true that nowadays we often install RCBOs which combine residual-current, overload, and short-circuit protection.

But your concern about nuisance trips is somewhat justified. If there is really only one RCD serving the entire house, which is very common for older installations, a ground fault will cause a larger outage.

Newer installations, however, typically use multiple RCBOs to reduce the blast radius. And really old installations, where small current leaks are more common, might not have an RCD anyway.

Also, in my experience, it's just not a problem in practice. I can count the number of nuisance RCD trips I've had in my life on one hand. And genuine faults are similarly rare. Other kinds of power outages are far more common.

> GFI outlets provide a very localized layer of safety [...] can be extraordinarily sensitive

I fully agree that this is an advantage.

A standard 30mA RCD or RCBO, as would be installed in Europe, should disconnect within 40ms at 150mA, but might take longer at lower currents. That could still be quite a substantial electrical shock. (I'm not qualified to say exactly how dangerous it still is, but I can attest to the fact that it can still hurt pretty bad even if the RCD trips.) A 5mA GFCI, as is typical in the US, provides a much larger safety margin. I guess nuisance trips would be a much bigger problem if the detection threshold for RCDs was lowered to 5mA.

So maybe we can agree that the perfect solution would be to have GFCI outlets everywhere? Because as it stands, you either have crude protection everywhere, or good protection limited to a few outlets.

One last note: Whether you have GFCI outlets or RCDs in your electrical panel, make sure to test them regularly via the test button! A faulty protection is no protection, and it's better to be safe than sorry.

Edit: One more thing worth keeping in mind is that, all else being equal, 230V drives almost twice the current as 120V, making the shock more dangerous and residual-current protection even more important.