In the UK, the owner is liable for identifying the driver at the time of the incident. This is how it works with e.g. rental cars. If the owner doesn't identify the driver, they get the points
In the US, you have the right to face your accuser. Since that's not possible with a camera, photo-based enforcement becomes a non-moving violation.
You can still point the finger at someone else when you get the ticket in the mail. Or just put a bunch of question marks in reply as it is on the State to prove their case, not for you to snitch on your own bad driving habits.
At least that is how it works in the state I live in.
That's obviously not true. Camera evidence is used as evidence of crimes all the time. Security cameras would be utterly worthless if they couldn't.
Right to face your accuser in that context means that you have the right to cross-examine relevant witnesses about how that camera evidence was collected and applied.
You lie, say it "Bob", then you're guilty of perverting the course of justice. They then write to Bob,
If Bob agrees, then he's also guilty of perverting the course of justice, but most of the time you'll both get away with it.
If Bob disagrees, then they look more into it.
If you refuse to answer then you're guilty of not saying who was driving the car, a completely separate offence to the original speeding one, and one which is typically more serious
In the US you can mow down a child, drive away, and despite people having your plates and giving them to the cops, they can't actually arrest you because it was only your car which was used to kill someone?
>In the US you can mow down a child, drive away, and despite people having your plates and giving them to the cops, they can't actually arrest you because it was only your car which was used to kill someone?
Not quite. In the US you get in trouble for driving off, but drivers that wait for the police to show up and then blame the child that they mowed down have a decent shot at having zero consequences, especially if the child was riding a bicycle.
That would run afoul of the right against self-incrimination in the US[1]. The government can't compel someone to admit they were driving, and can't punish people for refusing. The government has to provide proof they were driving.
Courts have held that people have less rights while driving then they do in other settings (such as walking down the street or as a passenger in a vehicle). For example, the doctrine of implied consent allows the government to compel you to submit to a blood alcohol test without a warrant. I wonder if something similar could be applied here.
I certainly support civil liberties, but they need to be balanced against the government's strong interest in preventing the bloodshed that comes from the reckless operation of vehicles.
I think there are many ways you could address this issue that don't involve circumventing constitutional rights.
Most of these systems take a photo of the car, which you can often use to verify who the driver was. For serious offenses you could chose to investigate who was driving and issue a normal ticket rather than an administrative fine. You can create laws about window tinting levels (where they don't already exist), and if you can't identify the driver because the car is violating those laws you can revoke the registration.
You could also institute a point system for vehicle registrations, where if an offense cannot be assigned to a person, it is assigned to the vehicle, and after points exceeded a certain limit the registration is revoked.
I don't know about NYC in particular, but in many jurisdictions a major reason that red-light cameras are treated like administrative fines rather than civil or criminal offenses is to avoid full due-process rights, making it harder to contest the fine, and saving money by making everything automated. Our safety is more important than that.
They could arrest you, because probable cause, but you would not have to plead guilty, which is what paying a ticket is. If speeding was an arrestable offense, they could arrest you but unless they could prove beyond reasonable doubt that you were driving they should not find you guilty. Plus what other commenter said about you can not force some one to incriminate themselves.
Well this latest outage has me forming a position that a backup is mandatory. I've been using Codex for adversarial-review, so with this outage I'm now going to ensure the repo is tooled up to use both agents, and when an outage hits just switch over and keep going.
If you mean Codex is better at planning, I've heard the exact opposite. I'm told it's a beast if you tell it exactly what you need as it will execute it to the T whereas Claude will push back or do its own thing either because it thinks it's wrong or because it's feeling lazy
gpt-5.4 xhigh is a beast you only wanna unleash on your most complex tasks or spend 30 minutes watching the model reasoning how to do a git commit. For everything else i'd happily use a saner model like sonnet.
I've started hitting Codex quota regularly for the first time the last couple of weeks, so I feel like they might be tightening the screws on the $20/month plan too. Someone paying for Max might have to work at it to hit the quota
I think the only correct answer here is: It depends, on so many different things. Usage is definitely way more generous with codex and it isn't even close.
And https://www.map.signalbox.io/, which tries to interpolate signal locations onto a geographic map (with the expected level of inaccuracy, though still not half-bad)
Surprised it allows FSD in such poor visibility conditions. Surely they need to do some work on a reported visibility confidence level where FSD disables if it is not confident in the amount of visibility it has.
Autosteer (lane following) will disengage if it can't see lane markings. I'm genuinely surprised FSD was active in these weather conditions (and as other posters have suggested, it may not be FSD at all).
Oh, the video capture device: because we had everything on analog CCTV, I had two analog TV tuner video capture cards in the server. Plain old 640x480 black and white analog video. When someone pressed the screen capture button on a Cocktail Console, I changed the channel on the video capture card to the appropriate channel, did a screen grab, and dumped the file in a folder on the server. People pressed it infrequently enough that two cards were fine to handle all the volume.
Every day I'd create a new mm-dd-yyyy folder for images to go to, and the Remote web site had a calendar on it. You could go to the site, click on the night you were there, see all the images captured by all people that night, and save your images if you felt like it.
Yep! First, here’s a video from the guy who developed all the hardware, Leo Fernekes. (He runs a great YouTube channel called Leo’s Bag of Tricks all about electronics and neat stuff you can do. Leo’s a genius.) Lots of details in here.
The Cocktail Consoles (as we called them) were all custom hardware. Everything was designed to be rock-solid both physically (bars are full of drunk people and liquids) and operationally (everything had to Just Work). Leo designed a core “motherboard” which was a PIC microcontroller (I forget the exact model) that did five main things: serial I/O for the buttons and joystick; serial I/O for the attached TV tuner; serial I/O for the attached pan-tilt video camera; audio from the telephone handset; and then multiplexing all of that serial I/O and sending it over serial to a central server (which I wrote — in Perl!) which then controlled all the Cocktail Consoles in the bar.
We used black and white cameras because they were both cheaper and also had much better sensitivity to low-light conditions (this has changed somewhat — but not entirely — in 20+ years) and black and white tube TVs because they were cheap. (This part was actually really dangerous — tube TVs hold enormous charges after they’ve been switched off, enough to kill someone, and we had the guts exposed on the insides of the Cocktail Consoles. Had to be very careful). We used public telephone handsets for the audio because of their durability, and video game buttons and joysticks so you could try very hard, and generally fail, to damage them.
The TV's, cameras, and telephone audio were all connected over an analog CCTV system. The camera was video source and the handset's microphone was the audio source for a given channel. The TV could be tuned to any channel, and was thus the video output device, and the handset's speaker was tied to the same channel. Thus, if you tuned to any camera, you would see and hear whatever was going on at that console, but not the other way around, so it was rather voyeuristic. If TV A was tuned to camera B, and TV B was tuned to camera A, that established a bi-directional link, which meant you could see and converse with the other person.
The serial data from all the microcontrollers were sent over serial-to-CAT5 converters, so the entire place was wired for Ethernet, but it was plain old serial over the wire. We then had these serial cards in a Dell server on the other end, which presented as roughly 100 serial ports on the server.
This was where I had to do a lot of learning. I was a good IP programmer, but I had to reach back into the depths of the kernel and learn all about TTYs and switch() and lots of other stuff that even in 2000 was sort of forgotten. It took me forever to find any good documentation on how to handle that many serial ports in a non-blocking way.
I kept asking Leo to just put a cheap Intel box in each machine and do it all over regular Ethernet, but he (rightly) kept insisting on this low-cost, rock-solid approach. Today the calculus would undoubtedly be different — you would do everything over IP — but back then Leo had a level of foresight I still admire.
Yep. 3rd and Bowery, before CBGB closed and the East Village went from the bohemian hipster world of RENT to the expensive place it is today. The Bowery had just barely changed from “don’t go there ever” to “oh, cool!”
For anyone looking to find out more about how computers work at a very basic level, I really recommend the book "Code" by Charles Petzold. Goes from first principles all the way up.
[0] https://www.youtube.com/watch?v=Uix9kXIMVRM