* I installed Fedora 43 and it (totally unsurprisingly) worked great.
    * I installed Steam from Fedora's software app, and that worked great as well.
    * I installed Cyberpunk 2077 from Steam, and it just... worked.

I later got a hankering to play Deus Ex: Mankind Divided. This time, the game would not work and Steam wasn't really forthcoming with showing logs. I figured out how to see the logs, and then did what you do these days - I showed the logs to an AI. The problem, slightly ironically, with MD is that it has a Linux build and Steam was trying to run that thing by default. The Linux build (totally unsurprisingly) had all kinds of version issues with libraries. The resolution there was just to tell Steam to run the Windows build instead and that worked great.

I've heard it said in jest, but the most stable API in Linux is Win32. Running something via Wine means Wine is doing the plumbing to take a Windows app and pass it through to the right libraries.

I also wonder if it's long-term sustainable. Microsoft can do hostile things or develop their API in ways Valve/Proton neither need nor want, forcing them to spend dev time keeping up.

This is where the argument goes back to Win32 is the most stable API in Linux land. There isn't a thing such as the Linux API so that would have to be invented first. Try running an application that was built for Ubuntu 16.04 LTS on Ubuntu 24.04 LTS. Good luck with that. Don't get me wrong, I primarily use and love Linux, but reality is quite complicated.

The exact same is true here. If large enough volumes of folks start using these projects and contribute to them in a meaningful way, then we end up with less noisy updates as things continue to receive input from a large portion of the population and updates begin more closely resembling some sort of moving average rather than a high variance process around that moving average. If not less noisy updates, then at least some fork that may be many commits behind but at least when it does update things in a breaking way, it comes with a version change and plenty of warning.

Yea, this is a really bad state of affairs for software distribution, and I feel like Linux has always been like this. The culture of always having source for everything perhaps contributes to the mess: "Oh the user can just recompile" attitude.

[1] PDF: https://app.sensortower.com/vgi/assets/reports/The_Big_Game_...

I also wonder about the developer availability. If you're capable of handling the more advanced APIs and probably modern hardware and their features, it seems likely you're going to aim at a big studio producing something that big experience, or even an engineer at the big engine makers themselves. If you're using the less demanding tech it will be more approachable for a wider range of developers and manageable in-house.

The support in this space from Valve has been amazing, I can almost forgive them for not releasing Half Life 3. Almost.

If they decide to do this in the gaming market, they don't need to mess up their API. They can just release a Windows native anti-cheat-anti-piracy feature.

Unless it's a competitive game and it's a significant improvement on current anticheat systems I don't see why game developers would implement it. It's only going to reduce access to an already increasing non-windows player base, only to appease Microsoft?

Also in order to circumvent a Windows native version wouldn't that be extremely excessive and a security risk? To be mostly effective they would need to be right down the 0 ring level.. just to spite people playing games outside of Windows?

On the other hand, using an official Microsoft anticheat that's bundled in Windows might not be seen as "installing a rootkit" by more privacy-conscious gamers, therefore improving PR for companies who choose to do it.

In other words, Microsoft would steamroll this market if they chose to enter it.

These things are always sold as general security improvements even when they have an intentional anti-competitive angle. I don't know if MS sees that much value in the PC gaming market these days but if they see value in locking it all down and think they have a shot to pull it off, they'll at least try it.

In theory a built in anti-cheat could framework have a chance at being more effective and less intrusive than the countless crap each individual game might shove down your throat. Who knows how it would look in practice.

Sometimes the API stability front causes people to wonder if things would be better if FreeBSD had won the first free OS war in the 90s. But I think there's a compromise that is being overlooked: maybe Linux devs can implement a stable API layer as a compatibility layer for FreeBSD applications.

It's like a flatpack, stabilized libraries based on Debian.

Running the anti-cheat in a VM completely defeats the point. That's actually what cheaters would prefer because they can manipulate the VM from the host without the anti-cheat detecting it.

Even if you run games in container you still need to expose the DRM char/block device if you want vulkan,opengl to actually work.

https://en.wikipedia.org/wiki/GPU_virtualization#mediated

WINE and Proton seems to always require hand holding and leaks dependencies on things installed on the host OS as well as dependencies on actual hardware. Used it for decades and it is great, but can never just relax and know that since a game runs now it will always run like is possible with a full VM (or with DOSBox, for older games).

Not while they continue to have the Xbox division and aspire to be the world's biggest publisher.

Unfortunately it seems supporting Linux natively is pretty quickly moving target, especially when GPUs etc are changing all the time. A lot of compatibility-munging work goes on behind the scenes on the Windows side from MS and driver developers (plus MS prioritizing backwards compat for software pretty heavily), and the same sort of thing now has a single target for peoples efforts in Proton.

It's less elegant perhaps than actual native Linux builds, but probably much more likely to work consistently.

It's sort of a philosophical bummer as an old head to see that native compatibility, or maybe more accurately, native mindshare, being discarded even by a relatively evangelical crowd but,

- as a Linux Gamer, I totally get it - proton versions just work, linux versions probably did work at some point, on some machines.

- as a Developer, I totally get it - target windows cause that's 97% of your installs, target proton cause that's the rest of your market and you can probably target proton "for free". Focus on making a great game not glibc issues.

I mostly worry about what happens when Gabe retires and Valve pivots to the long squeeze. Don't think proton fits in that world view, but I also don't know how much work Proton needs in the future vs the initial hill climb and proof-of-success. I guess we'll get DX13 at some point, but maybe I'll just retire from new games and just keep playing Factorio until I die (which, incidentally does have a fantastic native version, but Wube is an extreme outlier.)

2. You’re discarding the shifting software landscape. Steam OS and Linux are trending towards higher PC gaming market share. macOS has proven you don’t need much market share to force widespread (but not universal) compatibility.

3. I don’t see the value in a purist attitude around Linux gaming. The whole point of video games is entertainment. I’m much less concerned with if my video game is directly calling open source libraries then if my {serious software} is directly calling open source libraries.

Gaming is much more meaningful to me as a form of story and experience, and it is important to me that games keep working and stay as open and fair as possible. In the same way it is important I can continue to read books, listen to music or watch movies I care about.

With the container-based approach of the Steam Linux Runtime this should no longer be a problem. Games can just target a particular version and Steam will be able to run it forevermore.

Parity between DX12 and Vulkan is pretty high and all around I trust the vkd3d[0] layer to be more robust than almost anything else in this process since they're such similar APIs.

The truth is that it's just a whole lot harder to make a game for Linux APIs and (even) base libraries than it is to make it for Windows, because you can't count on anything being there, let alone being a stable version.

Personally I don't see a future where Linux continues being as it is (a culture of shared libraries even when it doesn't make sense, no standard way of doing the basics, etc.) and we don't use translation layers.

We'll either have to translate via abstraction layers (or still be allowed to translate Win32 calls) to all of the nasty combination of libraries that can exist or we'll have to fix Linux and its culture. The second version is the only one where we get new games for Linux that work as well as they should. The first one undeniably works and is sort of fine, but a bit sad.

0 - vkd3d is the layer that specifically translates D3D12 to Vulkan, as opposed to vkdx which is for lower D3D versions.

https://www.protondb.com/app/337000 for Deus Ex: Mankind Divided

and it worked surprisingly, also i see people joking about how win32 is the only stable api on linux xD. Also heard red dead redemption 2 also works well on linux that might be the next game i will check out.

I remember 15 or 20 years (has it been that long?) when the Haskell people like dons were banging on about: 1) Moore's law being dead, 2) future CPUs will have tons of cores, and 3) good luck wrangling them in your stone age language! Check out the cool stuff we've got going on over in Haskell!

I would also not blame Java for the worst of OO, all of that would have happened without it. There were so many OO culture languages pretending to that throne. Java got there first because of the aforementioned VM advantage, but the core concepts are things academia was offering and the industry wanted in non-Ada languages.

I would say Java also had a materially strong impact on the desire for server, database and client hardware agnosticism.

Some of this is positive reinforcement: Java demonstrates that it's better if you don't have to worry about what brand your server is, and JDBC arguably perfected ODBC.

Some of it is negative: a lot of the move to richer client experiences in the browser has to do with trying to remove client-side Java as a dependency, because it failed. It's not the only bridged dependency we removed, of course: Flash is equally important as a negative.

Really? Were there other major contenders that went as far as the public class MyApp { public static void main( nonsense?

Perhaps you would prefer a multi-paradigm programming language?

http://mozart2.org/mozart-v1/doc-1.4.0/tutorial/index.html

i.e. C++ primitive types are defined to be objects but do not fit into a traditional object-oriented definition of “object”.

In any case, Alan Kay is constantly clear that object oriented programming is about messages, which you can do in C++ in a number of ways. (I'm not sure exactly what Alan Kay means here, but it appears to exclude function calls, but would allow QT signal/slots)

This is because, conceptually, the object has total freedom to handle the message it was sent however it sees fit. Even if it's never heard of the method name before.

Again, this is not something you should do, but you can.

You're sinking into the Turing Tarpit where everything is possible but nothing of interest is easy. By morning, you'll be programming in Brainfuck.

Nothing to do with the objects of OOP.

What I’m saying is that the discrepancy between primitives in C++ and Java is entirely one of definition. Java didn’t actually change this. Java just admitted that “objects” that don’t behave like objects aren’t.

What I’m saying is that in both C++ and Java, there are a set of primitive types that do not participate in the “object-orientedness”. C++ primitives do not have class definitions and cannot be the base of any class. This is very much like Java where primitives exist outside the object system.

If the C++ standard used the term “entities” instead of “objects” I don’t think this would even be a point of discussion.

The entire design of C++ is built around eliminating all distinctions between primitive "entities" and user-defined "entities" in a way that Java just isn't. It's true that you can't inherit from integers, but that's one of very few differences. User-defined "entities" don't (necessarily) have vtables, don't have to be heap-allocated, can overload operators, can prevent subclassing, don't necessarily inherit from a common base class, etc.

C++'s strange definition of "object" is a natural result of this pervasive design objective, but changing the terminology to "entity" wouldn't change it.

If the intent was to erase all distinction between built-in and user-defined entities then making the primitive types unable to participate in object hierarchies was a pretty big oversight.

But at this point I think we’re talking past each other. Yes, in Java objects are more distinct from primitives than in C++. But also yes, in C++ there is a special group of “objects” that are special and are notably distinct from the rest of the object system, very much like Java.

But we agree on the direction, and that direction is not "Java [did something] by deciding everything must be an object," but its opposite.

If the definition of object is something like “an instance of a class that has state, operations, and identity” then C++ primitives are fundamentally not objects. They have no identity and they are not defined by a class. If “participates in a class hierarchy” is part of the definition, then C++ is way less OO than Java.

I don’t quite understand what your definition is, but you seem to be arguing that user-defined entities are more like primitives in C++, so it’s more object-oriented. So maybe “consistency across types == object orientedness”? Except C++ isn’t really more consistent. Yes, you can create a user-defined type without a vtable, but this is really a statement that user defined types a far more flexible than primitives. But also if “consistency across types” is what makes a language OO then C seems to be more OO than C++.

In part this is because by default even C++ class instances don't have identity, or anyway they only have identity in the sense that ints do, that every (non-const) int has an address and mutable state. You have to define a destructor, a copy constructor, and an assignment operator to give identity to the instances of a class in C++.

With respect to "participates in a class hierarchy", that has not been part of the definition of OO since the Treaty of Orlando. But, in Java, all objects do participate in a class hierarchy, while no primitives do, while, in C++, you can also create class instances (or "class" "instances") that do not participate in a class hierarchy (without ever using inheritance, even implicitly). So, regardless of how OO or non-OO it may be, it's another distinction that Java draws between primitives and class instances ("objects" in Java) that C++ doesn't.

In C++, everything is an object as defined by the C++ spec, but a lot of things are not objects in an OO sense.

In Java, almost everything is an object in an OO sense, but some stuff is definitely not.

There are other cases though. E.g. in C++ you could always have function pointers which were not objects and functions which were not methods. In Java you had to use instances of anonymous classes in place of function pointers, and all of your functions had to be (possibly static) methods.

In the C++ sense, but they don't have classes and don't participate in inheritance. Whereas the early-Java equivalents do.

STM shines in a concurrent setting, where you know you'll multiple threads accessing your system and you want to keep everything correct. And nothing else comes close.

Nothing came out of it unfortunately.

To me, the appealing things about STMs are the possibility of separating concerns of worst-case execution time and error handling, which are normally pervasive concerns that defeat modularity, from the majority of the system's code. I know this is not the mainstream view, which is mostly about manycore performance.

But if gaming is what you're actually interested in, then it's a pretty terrible buy. You can get a much cheaper x86-based system with a discrete GPU that runs circles around this.

I'm not in the market for a 5090 or similar, but the other day I was looking at a lower-end model, an AMD 9060 or Nvidia 5060. What shocked me was the massive variation in prices for the same model (9060 XT 16 GB or 5060 Ti 16 GB).

The AMD could be had for anywhere from 400 to 600 euros, depending on the brand. What can explain that? Are there actual performance differences? I see models pretending to be "overclocked", but in practice they barely have a few extra MHz. I'm not sure if that's going to do anything noticeable.

Since I'm considering the AMD more and it's cheaper, I didn't take that close a look at the Nvidia prices.

Looks. I'm not joking. The market is aimed at people with a fish bowl PC case that care about having a cooler with a appealing design, a interesting PCB colour and the flashiest RGB. Some may have a bit better cooling but the price for that is also likely marked up several times considering a full dual tower CPU cooler costs $35.

I am not a tech wizard, but I think the major (and noticeable) difference would be available tensor cores — that currently nVidea's tech is faster/better in the LLM/genAI world.

Obviously AMD jumped +30% last week from OpenAI investment — so that is changing with current model GPUs.

Compared to my CPU (9950X3D), it's got a massive monolithic die measuring 750mm2 with over 4x the transistor count of the entire 9950X3d package. Beyond the graphics, it's got tensor and RT cores, dedicated engines for video decode/encode, and 32GB of DDR7 on the board.

Even basic integrated GPUs these days have far surpassed GPUs like the RTX 970, so you can get a very cheap GPU that gets power through the CPU socket, at MSRP.

I'm a retired data center electrician, and my own GPU's has been "loose" at least more than once. Really make sure that sucker is jammed in there/latched.

In fairness, the graphics card has many times more processing power than the rest of the components. The CPU is just there to run some of the physics engine and stream textures from disk.

Because the price is too low, more people want to buy a graphics card than the number of graphics cards that can be produced, so even people who would love to pay more can't get one.

Scalpers solve this mismatch by balancing the market: now people who really want to get a graphics card (with a given specification) and are willing to pay more can get one.

So, if you have a hate for scalpers, complain that the graphics card producer did not increase its prices. :-)

The whole problem with the DOM is that it has too many methods which can't be phased out without losing backwards compatibility.

A new DOM wasm api would be better off starting with a reduced API of only the good data and operations.

The problem is that the DOM is still improving (even today), it's not stabilized so we don't have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two.

New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications:

- being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition.

- the improved attr() api which can move a lot of an app's complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time.

And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications.

Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn't we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures.

TL;DR: It's still too early to work on a DOM api for wasm. It's better to wait for the DOM to stabalize first.

That is the trend we face now days, there is too less stable stuff around. Take macOS, a trillion dollar company OS, not an open source without funding.

Stable is a mirage, sadly.

The goal behind the argument is to grant WASM DOM access equivalent to what JavaScript has so that WASM can replace JavaScript. Why would you want that? Think about it slowly.

People that write JavaScript for a living, about 99% of them, are afraid of the DOM. Deathly afraid like a bunch of cowards. They spend their entire careers hiding from it through layers of abstractions because programming is too hard. Why do you believe that you would be less afraid of it if only you could do it through WASM?

I see good use cases for building entirely in html/JS and also building entirely in WASM.

The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists.

It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount of work work it’d take to do this.

Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?

yes, e.g. with Leptos you don't have to touch JS at all

https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

It is managable if you avoid js wasm round trips, but if you assume the cost is near zero you will be in for a unpleasant surprise.

When I have to do a lot of different calls into my wasm blob, I am way way faster batching them. Meaning making one cal into wasm, that then gets all the data I want and returns it.

But further, WASM is more than just a browser thing at this point. You might be running in an environment that has no DOM to speak of (think nodejs). Having this bolted on extension simply for ease of use means you now need to decide how and when you communicate its availability.

And the benefits just aren't there. You can create a DOM exposing library for WASM if you really want to (I believe a few already exist) but you end up with a "what's the point". If you are trying to make some sort of UX framework based on wasm then you probably don't want to actually expose the DOM, you want to expose the framework functions.

Aren't the framework functions closely related to the DOM properties and functions?

It was interesting hearing the names of the locations and bridges that previously meant nothing to me (except the golden gate).

It's free to watch on youtube at the moment: https://www.youtube.com/watch?v=Qy9XYQBBIJ4

I visited NYC a few weeks ago and was instantly reminded of how much the traffic fucking sucks :) While I was there I actually thought of Waymo and how they'd have to turn up the "aggression" slider up to 11 to get anything done there. I mean, could you imagine the audacity of actually not driving into an intersection when the light is yellow and you know you're going to block the crossing traffic?

Who knows, maybe we’ll start taking our cues from our polite new robot driver friends…

Several of the hiking trails I frequent allow dogs but only on leash. Over time the number of dogs running around off leash grows until it’s nearly every dog you see.

When the city starts putting someone at the trailhead at random times to write tickets for people coming down the trail with off-leash dogs suddenly most dogs are back on leash again. Then they stop enforcing it and the number of off-leash dogs starts growing.

But I’m with you on more enforcement. I’m totally fine with automated traffic cameras and it was working great when I was in China - suddenly seemingly overnight everyone stopped speeding on the highways when I was in Shanghai, as your chances of getting a ticket were super high.

https://www.iihs.org/research-areas/red-light-running

So let's use that as an upper bound.

How many people were killed by these backups you're talking about?

They are mostly located in sane places.

Apps like Waze consume this API and warn drivers if they’re at risk of getting caught. It’s the deterrence/slowdown at known risky spots they’re after, not the fine, I guess.

I heard that apps warning drivers this way are illegal in Germany?

In my city in Canada, that camera would be in the 50 zone.

When I lived in a small town in Sweden, the problem was that at night some drivers would blow down the country roads and straight through the small towns at crazy speeds assuming that there was nobody around. On some nights/weekends there were also zero police on duty in the whole municipality, they would have to be called in from a neighboring, larger, municipality.

Same as the difference between an obvious speed trap and a "gotcha" speed trap.

So nudging, sort of. There’s a lot of public support for that.

Oh and it's not a bill, it goes through the legal system so people have the right to argue it in court if they want.

Plate lookup returns state/municipal as the owner -> ticket gets discarded.

"The registered owner of the motor vehicle involved in the violation is responsible and liable for paying the uniform traffic citation issued for a violation"

http://www.leg.state.fl.us/Statutes/index.cfm?App_mode=Displ...

In the same way, it's the vehicle owner's responsibility to make sure their car is not driven through a red light. If they abdicate that responsibility, they aren't innocent!

Anyplace with the slightest adherence to the rule of law requires the state to positively identify an actual person, not a vehicle owned by a person, that is responsible for a moving violation. And then personally serve that person rather than just coming up with this absolute bullshit excuse that an unreliable mail system with a letter dropped god knows where somehow is legal service.

1. Camera-issued tickets are not moving violations

2. Your car will not be impounded for failure to pay (maybe unless you have many, many unpaid tickets)

If the photo is bad, you can dispute it! That isn't presumption of guilt, it's the legal system working exactly as intended: one side presents their evidence, and the other side has a chance to respond.

Even if USPS loses 0.5% of mail (I am skeptical; that seems crazy high) the state sends at least three notices, so the chances of you missing every notice of your infraction is something like one in a million.

1. Allow someone else to drive your vehicle

2. That person runs a red light

Your responsibility as the vehicle owner is to either not do step 1, or only do it for people whom you trust will not do step 2.

The spouse thing honestly seems fine — it just means that you're both responsible for paying the ticket, rather than you alone — but if you have an issue it's with the property laws, not the red light cameras.

[1] https://www.nyc.gov/site/finance/vehicles/red-light-camera-v...

https://www.nbcnews.com/id/wbna32806142

Voters just really don't like them.

The cameras would get installed at busy intersections with lots of minor infractions to collect fines on rather than unsafe intersections that had lots of bad accidents. And then, when the revenue was insufficient, they would dial down the yellow light time.

Consequently, and rightly, Americans now immediately revolt against traffic cameras whenever they appear.

(San Diego was one particularly egregious example. They installed the cameras on the busy freeway interchange lights when the super dangerous intersection that produced all the T-bone accidents was literally one traffic light up the hill. This infuriated everybody.)

Last time I was in China drivers simply go through four way intersections at top speed from all directions simultaneously. If you are a pedestrian I hope you're good at frogger because there is a 0% chance anyone will stop for you. I really wonder how self driving cars work because they must program some kind of insane software that ignores all laws or it wouldn't even be remotely workable.

Then I came back to the US and forgot to switch back to US-style street crossing behavior at first. No physical harm done, but I was very embarrassed when people slammed on their brakes at the sight of me in the middle of the road.

I know a lot of foreigners like Japan for motorcycling specifically because you can "white line" in most places, and the drivers are attentive.

The one quirk I thought was most interesting was Crab Angle Stops or when at a T shape stop lights that have an additional stop light 20 feet further from the intersection. Sometimes the cars will align diagonally to allow more traffic per light and let whoever is in front have a better angle to see traffic on small roads with poor visibility. Then when the light turns green the diagonally aligned cars move back to normal.

Like ////// to - - - - - -

Officially, the 道路交通法 (Road Traffic Act) doesn’t say “you must angle.” It just requires drivers to stop at the line and confirm safety before entering.

The diagonal stop is more of a local driving custom (practical adaptation) rather than a codified rule.

Any individual infraction might only be a small fine, but it adds points to your license. Collect enough points and you risk license suspension.

I’ve known a couple people who got close to having enough points for license suspension. They drove perfectly for years.

I'm less concerned with a little speeding than I am with blowing through lights and stop signs.

If they run a red light today there is some small chance they will injure/kill someone.

If they run a red light with a camera, there is a 100% chance they will receive a ticket.

The key factor is not the magnitude of the penalty (i.e. whether someone dies or they receive a fine) but the chance that they will encounter the penalty.

Edit: let me clarify: there is a camera on every intersection which automatically gives a ticket to everyone who blocks for >5sec. That works.

The nominal regulations on automotive behavior is pretty sufficient throughout the US, the main problem is that in most parts of the country traffic law may as well be a dead letter.

It's enforced in the worst congested zones, the intersections around tunnel entrances and midtown, but as I said in my other comment usually by parking enforcement not NYPD.

A workaround in the law is to throw your turn signal on if stranded in the box, this doesn't count as blocking the box.

> Quick, clear and consistent also works in controlling crime. It’s not a coincidence that the same approach works for parenting and crime control because the problems are largely the same. Moreover, in both domains quick, clear and consistent punishment need not be severe.

https://marginalrevolution.com/marginalrevolution/2015/09/wh...

I think this could be an interesting unintended consequence of the proliferation of Waymos: if everyone gets used to drivers that obey the law to letter, it could slipstream into being a norm by sheer numbers.

Their effect on traffic and how drivers behave will be similarly amplified. It could turn out to be disastrous for Waymo. But I suspect that low speed limits in New York will work to Waymo's favor.]

A bounty program to submit dash cam video of egregious driving crimes. It gets reviewed, maybe even by AI initially and then gets escalated to formal ticket if legit. Once ticket is paid, the snitch gets a percentage.

Again, I am fundamentally against something like this though, especially now.

Would you be bothered if someone was following you all day, making recordings every time you didn't signal for exactly 5000ms before a lane change, or 300' before a turn? how about not stopping for a full three seconds, or driving an extra 100' in the left lane than necessary?

three felonies a day

And they're not felonies, they're cheap tickets that probably won't even add points to your license.

and i'm sorry, i can't take anyone seriously that claims they both know and always follow every vehicle code, wherever they are and wherever they travel. I do understand it allows one to shake their head in disdain for the unwashed cars driven by the lesser drivers of our society.

I can follow anyone, including federal agents, local and state law enforcement, CDL drivers; i will catch something that is a violation of the vehicle code.

If you live anywhere near the gulf coast, i'd be happy to tail you for a couple of days and point out every violation you make.