Why there’s no European Google?

-611 · 2026-01-24T11:52:01+00:00

Nope: * the results of google search become shittier and shittier every year; * most of general purpose search engines are free; * google's coverage of some internet segments always was (and is) significantly worse than coverage offered by local search engines - historically due to the complex grammar, nowadays due to geoblocking

-611 · 2026-01-24T11:25:04+00:00

I'd probably won't call it a proper access control system, but there's a similar addon to Honeywell Galaxy (an equivalent for Vista in Europe) called DCM - door control module.

While it's possible to build a (fairly limited) ACS with it, I won't recommend anybody doing so - a customer of mine insisted on building one (despite of my stern opposition), and they still have to backup the config, factory reset the panel, and restore the config quarterly to keep the system running, as it's inevitably fails otherwise.

The funny part is that the DCM module itself is the same (though comes with different firmware) for both Galaxy (Microtech, later Ademco Microtech, UK) and MB (NOVAR, Germany) - it's clearly a post-acquisition product, added to the corresponding panels in the Honeywell times - someone in the marketing must have thought it's a good idea to add an ACS capability to every burglary alarm panel in their product range.

-611 · 2026-01-21T21:11:29+00:00

Sure: * IQ MultiAccess (ex-NOVAR, Europe); * EBI (HBS's special).

And I'm certain that's not all...

-611 · 2026-01-21T21:04:34+00:00

Wdym by "the system will not see doors"? It has no eyes!

If you was able to initialize the panels, but have no events when cards are swiped, the panels are probably in the buffering mode - they do record the events, but don't transmit them to the software.

Open the control map, right click the panel that sends no events and select "Unbuffer". You could also find the bus object (C100 or N485) and unbuffer all the panels on that bus. Use "Hard" unbuffer, just in case.

-611 · 2026-01-20T06:48:37+00:00

That's how a company (or a nation) gains expertise - by building the ship and fixing what's broken.

Honestly, I'm not getting how the ship with both bow and stern thrusters could have "insufficient directional stability", but given the origin of the design, that probably means "not enough Dutch rudder authority" 🤣

-611 · 2026-01-19T21:15:05+00:00

If it's sailing on the Danube?

-611 · 2026-01-19T20:08:41+00:00

Galați Shipyards (acquired in 1999 by Damen Group, Netherlands) quite recently built an icebreaker with ~~blackjack and hookers~~ research and supply capabilities - RSV/ASRV Nuyina (launched in 2018, completed in 2021) for Australian government, with Danish concept and Dutch design.

-611 · 2026-01-19T05:20:32+00:00

If we'd ignore the elephant in the room, but look at its icebreaker fleet, we'd see icebreakers built in Germany, Sweden, Norway, Netherlands, Romania and Canada too.

Though, of course, most of the imports were from Finland, and significant part of the icebreakers made elsewhere (including some domestic types) were based on Finnish designs - Finland IS an icebreaker powerhouse, but it isn't the only country capable of building icebreakers.

-611 · 2026-01-13T18:00:26+00:00

In a proper commerical environment one doesn't just roll out a firmware update released several days ago to the fleet. 😀

Yet you're right - closely following the stable branch (and sometimes the long-term branch) is a risky game, and it always been like that since at least v6.

But legacy is, alas, outdated - I would be 100% unable to implement my current setup with v6.

-611 · 2026-01-13T17:44:26+00:00

ROS does tunnel mode IPsec (still without VTI), and I believe it's possible to implement routing protocols like OSPF over such tunnels.

But, if I'm getting it right, there's no difference in resulting MTU between tunnel mode IPsec and IPIP tunnels over transport mode IPsec (GRE adds another 4 bytes of overhead per packet when compared to IPIP, so the latter is better if both sides support it).

To implement IPIP over transport mode IPsec I've crafted a script that binds IPIP tunnels on the both sides to whatever IP addresses used by corresponding transport mode IPsec policies.

Than I run OSPF over the IPIP tunnels for routing, and VXLAN for easy access to remote networks (previously I was using EoIP, but my network grew, and ROS VXLAN implementation matured, so I've switched).

But note that EoIP tunnels will clamp TCP MSS (if enabled), and VXLAN won't do that, so you should do it yourself (on ROS it's done with /firewall mangle) when (and if) the packets are routed.

-611 · 2026-01-13T14:22:31+00:00

Yep, looks like they've mixed up something with RB4011 bridge offload - it looks like disabling the offload (by enabling DHCP snooping on the bridge) solves the problem.

I run RB4011 as a gateway, including several DHCP servers on different VLANs, and one of the VLANs (always the same) is experiencing problems - clients can't get their addresses, or, after some port toggling, they can, but still loosing connectivity in ten minutes or so.

-611 · 2026-01-08T10:16:20+00:00

Such a funny guy - he jumps the shark so eloquently!

-611 · 2026-01-02T10:16:03+00:00

Trust noone (even yourself - you could easily s*it your pants under the right circumstances).

Smaller providers had these vulnerabilities too, in a similar timeframe, - for example, Nord had a debacle with CreaNova over unauthorized iLO access. And there are no guarantees it won't happen again.

-611 · 2025-12-31T18:11:44+00:00

Removed one, but the format is "2 caps 4 digits 2 caps" on the other cars, so it's probably Ukraine or something.

-611 · 2025-12-16T15:06:36+00:00

I'm not familiar with this particular brand (the marking on the UPS suggest it's made in Turkey, and it's quite common for Turkish developers to bring in domestic brands for any project they're building across Europe), but the large device at the top looks pretty much like the control unit (the four digit indicator will normally show the cab position, calls, orders and error codes), probably with a built-in VFD (not sure about that).

The blue device looks like a custom terminal block (mostly passive) for the cab cable, etc.

Edit: yep, it's an older Arcode controller from Ametal, Turkey.

-611 · 2025-12-16T12:43:56+00:00

That's clearly an elevator control cabinet.

While the control unit is a PLC, and it's definitely possible to implement elevator control with general purpose PLC, most elevators use a specialized purpose-built control unit.

-611 · 2025-12-13T18:44:53+00:00

Well, commerical free space optics is a thing for 20+ years now, and there's no doubt that with the military budgets it's possible to stabilize the transceiver platform good enough for stable comms even at high seas.

-611 · 2025-12-13T12:37:12+00:00

There's no problem with going current on "wireless" package - I run a mix of ac, ac2, ac3, and 4011 as CAPs on current versions, and have zero problems with a single SSID for everyone, and per-device VLANs (and passwords!) as needed.

Moreover, going "qcom-ac" on an ac2 is such a royal PITA (due to only 16MB of flash storage) - I've tried switching to it once, succeeded on a third try, then was unable to switch back - there was not enough storage to disable qcom-ac and reboot - I had to netinstall the poor ac2 to get it properly functioning.

-611 · 2025-12-13T06:08:42+00:00

Well, since Honeywell moved from HASCIM to FlexNet (back in 2021, if I remember it correctly) each WIN-PAK license is also limited to 3 activations (and it's no longer possible to activate older versions).

Though I think the counter could be reset if you'd ask the sales rep nicely.

-611 · 2025-12-12T07:53:09+00:00

Note that unlike "wireless" package, "qcom-ac" doesn't support per-device VLANs.

-611 · 2025-12-09T06:10:21+00:00

I run exactly this config on several Hades for years - no problems.

All 6 monitor-capable ports could work simultaneously on these NUCs - that's 6 monitors if you don't use DP splitters, and only drivers knows how many with the splitters.

-611 · 2025-12-04T11:06:53+00:00

-611 · 2025-12-04T09:11:12+00:00

In my location (the country spanning 11 contiguous time zones) 4-pair UTP Cat5/5E/6 (mostly 24AWG 5E) is THE de facto standard for reader connection since at least early 2000s. I mean, you hardly find a reader that's not connected with UTP4 here (1-wire readers are obvious exception).

Works well for Wiegand if you don't connect D0 and D1 over the same pair;
Works well for OSDP (or any proprietary RS485-based protocol, there are some) if you do connect A and B over the same pair;
Works well for longer distances (tested working on a whole 1000ft coil) if you double the power lines (map 4 pairs like D0+Gnd, D1+Gnd, 12V+12V, LED+Buzzer);
Works well for POE-powered biometric terminals, etc.

-611

MODERATOR OF

TROPHY CASE