What I find most interesting about the computer side of traffic signal controllers is the interlock design needed to prevent a glitch or memory fault from activating conflicting phases at once, eg two intersecting approaches getting green simultaneously. That's about as safety-critical as it gets for a piece of everyday infrastructure. Would've liked to see more depth on that, though I imagine the specifics are controller/vendor-specific.
I think that interlock design also goes some way toward mitigating the security risks ASCT systems would otherwise pose, as mentioned in the article. On any decent controller, even the control room shouldn't be able to deliberately trigger conflicting phases.
A typical signal cabinet has a conflict monitor, also called a malfunction management unit, that’s physically distinct from the controller. It supervises the controller outputs and can force the signal to all-way flashing red if green (or yellow or WALK) is shown for conflicting phases or if red or DON’T WALK is missing. More sophisticated units can also detect problems with sequencing or change or clearance interval timing.
Country of origin doesn't tell you much on its own. Linux is American too, and few question its trustworthiness. What matters is the code being open source and auditable, not where the maintainers live.
"Linux" doesn't keep centralized records that the government can get their hands on. The fact is that the government in the US can (and does) march into US companies and demand access to their data. The government will install their devices on the company's network and even take over entire parts of their offices. What your data sits, who has access to it, and what kind of record the local government has of abuses of their authority are very important things to consider. Much more important than if the code is open source.
This has all the hallmarks of a "gethomeitis" disaster, where the urge to push on overrides better judgment about going around and doing things properly.
Hah, my dad made something like this for me when I was a kid using a weed eater engine, with a makeshift lever as a clutch to engage/disengage it. This looks about as makeshift, I wouldn't trust it for serious use.
>The Nintendo Switch (which runs Linux) was a favorite of cheaters after jailbreaks came out.
If you're saying the Nintendo Switch system software is Linux-based, I don't think that's correct. It's a proprietary system based on a microkernel architecture.
It's proprietary, but they kit bashed a bunch of existing components (iirc, Android's surface flinger, the Nvidia embedded linux drivers, and the freebsd network stack)
There's something deeply satisfying about compiling a Win32 desktop application and knowing that single binary will run unmodified on essentially every Windows machine from XP onward, and look nearly identical doing it. High-DPI is the one real caveat, but even that's manageable with a manifest. I'm not sure any other platform-native API comes close to that combination of reach and consistency. Running them on other operating systems is really just a bonus.
They exist but they’re in the minority. Compare this with the Linux world, where userspace compatibility between one major distro release and the next, 12 months apart is very much a roll of the dice.
To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this.
But if you want to use... anything else, then it's unlikely to work at all unless you are very specific about your target. There isn't one company deciding that glibc or mesa or whatever is binary backward compatible on every kernel for every platform forever. Microsoft is, somewhat, one such company. That's why System32\*.dll have such stable interfaces -- it's their job to translate whatever late 90s system/graphics facilities some boomer dreamed up into whatever the current Windows hodgepodge of system services support. It's no wonder Microsoft is trying to drop support for hardware like crazy.
This implicit compatibility isn't true for all Windows programs, though. Consider Visual Studio. Couldn't compile my console program on my computer and run it on my dad's computer. He had to first install the "Redistributable," which for him and most people might as well be a rootkit and a super scary virus program bad guy.
> To be fair, if you use only the Linux syscall interface, then a program that you compiled on x86 in the 90s will probably still run anywhere today. Linus is adamant about this.
This is frankly the opposite of how it should've been. Who cares that the kernel ABI doesn't change from release to release? As an end-user, I couldn't care less. Even as a developer I care very little indeed, because I'm not writing drivers. I'm almost never programming directly against the kernel's interface but rather using my language's standard library, which is already an abstraction over the kernel interface.
Platform vendors (this includes distro maintainers) should recompile and re-package libraries for each new ABI in each OS release, done. End-users won't ever notice, they can run their applications portably because the user-mode library ABIs haven't changed... Which is what Win32 has done, and what glibc has consistently failed to do.
The funny thing about the glibc situation is that glibc really doesn’t provide improvements to any of the kernel interfaces or really any comfort stuff for developers. If anything the fact that it is bound by the C standards makes it worse than using the kernel API directly besides that for whatever reason the kernel headers seem to lack a fair number of definitions. That could just be a me problem though.
To add on to this, in some organizations it's easier to assess risk according to RMF and similar frameworks if the application ships with stunnel and is configured from within than it is for the application to require a system-level VPN like Wireguard.
That said, I think Wireguard is easier to analyze on the wire since it has a known binary signature from the first 4 bytes, while stunnel tunnel is indifferentiable from web browsing traffic. For a bad actor looking into exfil or C2, this means an stunnel is probably the sneakier and thus more reliable method of encryption on the wire compared to wireguard.
I reckon hackers get a thrill out of doing the inputs themselves. They seem to be able to disregard the fact they've got an unfair advantage, pretending that they are still achieving something by their acts.
Where vision based AI will start running riot is in games like Runescape where macroing is a huge problem. I expect it will become undetectable and therefore unbannable.
There was a federal civil rights investigation into the officer's conduct. There was also an unsuccessful attempt to indict him before a grand jury. The shooting was reported on the front page of the New York Times on Aug. 12 2014. I don't think this example helps you.
You don't seem to understand the context of the post you're responding to, which is not referring to Michael Brown, but to the suspicious deaths of DeAndre Joshua and Darren Seals among others.
You can pretend you are the reasonable one here, but you're not. As someone who has been watching this for a while you look to me like a sea lion. Treating your position with disdain is the more rational of these two position.
Do I have evidence of a high level criminal conspiracy to which I have access to none of the tools or methods that could possibly obtain evidence, evidence that if it did exist would surely put my own life in danger?
Upvotes in this local propaganda war have no bearing on veracity or constructive behaviour, it just means the faction you can be slotted into is more wont to press the upvote arrow on the type of message you keep on posting.
I think that interlock design also goes some way toward mitigating the security risks ASCT systems would otherwise pose, as mentioned in the article. On any decent controller, even the control room shouldn't be able to deliberately trigger conflicting phases.
reply