>Ever tried to call someone over the internet? Well, now you need a publicly reachable device.
Uhh... Is this the '90s? People don't type in IP addresses (or phone numbers, back in the day) to connect with other people anymore. They connect to a common, publicly reachable server that deals with peers being behind NAT.
Most video calling software uses STUN NAT hole punching and not central relay servers. You are definitely publicly routed when you call through Google Meet or WhatsApp or FaceTime
It doesn't really matter. Any communications provider must keep call records for the FSB, so routing them through central servers and recording there is the only option anyway.
Of course it matters. STUN isn't theoretical, it's in actual, practical use across a great many things. There's plenty of things that aren't "calls" in a telecommunications sense. Discord, Telegram, Zoom, Slack, Jitsi, and far more. And there are plenty of other things entirely that use the same tactics to get direct peer-to-peer connections.
That is a quite extreme outlier, then. Hardly relevant to the global IPv6 and peer-to-peer conversation we're having here, and your objection still only applies to one narrow use of the technology under discussion.
>That is a quite extreme outlier, then. Hardly relevant to the global IPv6 and peer-to-peer conversation we're having here
It's China with it's 1bn of internet users and 2bn+ devices .
If you're happy to exclude half of the internet from your "global peer-to-peer conversation", then you don't need ipv6 either, just use the Chinese IPs for your own purposes, there are plenty of them.
Actually this is the attitude I am seeing from the ipv6 zealots all the time: blatant disregard of reality. Nobody wielding and non-negligible amount of power wants peer-to-peer communication. Companies don't want it, governments don't want it, large masses of people who want a person with a vested interest to be responsible for the link quality don't want it.
What ipv6 zealots don't realize is that ipv6 will not bring them their coveted p2p, because, guess what, incoming connections are to peasant computers are blocked by ISPs by default.
As I said, p2p benefits even you right now, today, on IPv4, despite your unwillingness to acknowledge it. I've never even owned an IPv6 address in my life, so this mental image you've painted of myself and of our interaction is quite inaccurate.
You've taken this conversation quite far off its rails. This started due to your objection about phone calls not benefiting from P2P connections, which as I said are one narrow use of the overall technology. P2P connections are still useful. Nobody's blocking China. China connects peers, too.
I'd also like you to clarify something for me, earlier you mentioned P2P doesn't work, specifically for calls, specifically for your country, because all calls need to be transported through the FSB. This isn't any sort of accusation, I fully believe you are in China, but I'm curious what the FSB has to do with you in that case?
You don’t need to allow peer-to-peer connections with IPv6. They’re easier to allow and book keep - but also easier to block. The workarounds for peer-to-peer with IPv4 NAT are extremely difficult to detect and stop (STUN, various proxying setups, etc.). A lot of software does it though, for performance reasons. CGNAT is quite expensive and error prone, and causes a lot of support calls too.
Every ISP router I’ve gotten (US, India, Brazil, Germany) in the last few years had IPv6 AND default block for inbound connections in the stateful firewall. Which is fast, cheap, and easy. And most of my traffic (~90%) ended up being over IPv6 by default in a dual stack environment, with certainly no apparent latency penalty. In most situations, a latency decrease near as I can tell, as I didn’t need to route through someone else’s random servers at first to initiate connections for certain kinds of traffic. And no, I wasn’t torrenting.
The hilarious thing here is what is even the fight about?
There are too many humans on this planet for even one IPv4 address per, and too much traffic/connections to sanely coalesce every thing under CGNAT - and why go through all the trouble, when IPv6 is simpler and faster at an infrastructure level anyway than multiple layers of CGNAT and dealing with all the crazy BS that comes up when you have that much address translation and packet rewriting going on.
Which, notably, is more expensive than the more straightforward stateful firewall stuff anyway.
No one is intentionally going to IPv4 unless they have no choice due to backwards compatibility, and that is an increasingly shrinking pie. In another 5-10 years as the old consumer gear finally EOLs, it’s probably going to only be used for niche backwards compatibility (like RJ11 and the old school telephone system), and corporate use where their EOL timelines look more like 50 years. But pipe over tunnels over IPv6.
Which works great BTW - 90% of my active IPv4 usage is for internal servers using Tailscale, which is all actually transported over IPv6. And it does that because while it can use CGNAT punching tricks with TUN/S, etc. it’s faster to just connect directly (through the firewall rule I explicitly created to allow this).
And that is just because the Tailscale software prefers to display/default copy-paste it’s internal IPv4 addresses over internal IPv6 addresses for some reason, which I’m sure will change at some point.
It doesn't really matter where I live. In any case, "worksforme" ia not a solution.
We are discussing a supposedly global standard, which should work and be better for everyone, including Russia, China, Iran, everyone.
You know, Western politicians usually have exactly the same desires as their authoritarian Eastern counterparts, they are just unable to express them publicly. But hey, ipv6 is a niche problem discussed only by geeks, they don't actually have to say anything publicly about it, they can just silently sabotage its implementation.
China obviously has a state security service, but it doesn't really matter, I used FSB as a generic term for a law enforcement agency which tells ISPs what to do.
A possible compromise could be to be able to tell the compiler, "I don't care about structured exceptions anywhere else, so do all your instruction reordering stuff there, but this one section of code I know could throw structured exceptions, so be more conservative here." It might need to generate duplicated code for some functions, though.
The whole point of the optimizer is that it can detect inefficiencies by treating every statement as some combination of simple, fundamental operations. The compiler is not seeing "call memset() on pointer to heap", it's seeing "write of variable size" just before "deallocation". For some, optimizing that will be a problem, for others, not optimizing it will leave performance on the table.
There are still ways to obtain the desired behavior. Just put a call to a DLL or SO that implements what you need. The compiler cannot inspect the behavior of functions across module boundaries, so it cannot tell whether removing the call preserves semantics or not (for example, it could be that the external function sends the contents of the buffer to a file), so it will not remove it.
A modern compiler may also completely remove malloc / free pairs and move the computation to the stack. And I do not see what this has to do with C, it should be the same for most languages. C gives you tools to express low-level intent such as "volatile", but one has to use them.
Strong disagree. In C, malloc and free are functions, and I expect no magic to happen when calling a function. If malloc and free were keywords like sizeof, it would have been different.
Your problem is that you're treating words such as "function" and "call" as if they had meaning outside of the language itself (or, more specifically, outside of the C abstract machine), when the point of the compiler is precisely to melt away the language parts of the specified program and be left with a concrete program that matches its behavior. If you view a binary in a disassembler, you will not find any "functions" or "calls". Maybe that particular architecture happens to have a "call" instruction to jump to "functions", but these words are merely homophones with what C refers to as "functions" and "calls".
When you "call" a "function" in the source you're not specifying to the compiler that you want a specific opcode in the generated executable, you're merely specifying a particular observable behavior. This is why optimizations such as inlining and TCO are valid. If the compiler can prove that a heap allocation can be turned into a stack allocation, or even removed altogether (e.g. free(malloc(1ULL << 50))), the fact that these are exposed to the programmer as "functions" he can "call" poses no obstacle.
Closest to what you say that I can find is 5.1.2.3 §4 of N3096
In the abstract machine, all expressions are evaluated as specified by the semantics. An actual
implementation need not evaluate part of an expression if it can deduce that its value is not used
and that no needed side effects are produced (including any caused by calling a function or through
volatile access to an object)
Problem is, calling external library function has a needed side effect of calling that library function. I do not see language that allows simply not doing that, based on assumed but unknown function behaviour.
The behavior of the standard functions is not unknown, it is at least partially specified. If a user overrides them under the mistaken assumption that a call in source translates in a 1-to-1 correspondence to a call in binary, that's their problem.
Thanks, I did read it! Things like footnote 236: "This means that an implementation is required to provide an actual function for each library function, even if it also
provides a macro for that function", where macro is shown to use compiler builtin as an example.
Again, could you please explain how compiler can decide to remove call to a function in an external dynamically loaded library, that is not known at compile time, simply based on the name of the function (i.e. not because the call is unreachable)? I do not see any such language in the standard.
And yes, calling unknown function from a dynamically loaded library totally is a side effect.
> Again, could you please explain how compiler can decide to remove call to a function in an external dynamically loaded library, that is not known at compile time, simply based on the name of the function (i.e. not because the call is unreachable)? I do not see any such language in the standard.
> And yes, calling unknown function from a dynamically loaded library totally is a side effect.
The thing is that malloc/free aren't "unknown function[s]". From the C89 standard:
> All external identifiers declared in any of the headers are reserved, whether or not the associated header is included.
And from the C23 standard:
> All identifiers with external linkage in any of the following subclauses (including the future library directions) and errno are always reserved for use as identifiers with external linkage
malloc/free are defined in <stdlib.h> and so are reserved names, so compilers are able to optimize under the assumption that malloc/free will have the semantics dictated by the standard.
In fact, the C23 standard explicitly provides an example of this kind of thing:
> Because external identifiers and some macro names beginning with an underscore are reserved, implementations can provide special semantics for such names. For example, the identifier _BUILTIN_abs could be used to indicate generation of in-line code for the abs function. Thus, the appropriate header could specify
#define abs(x) _BUILTIN_abs(x)
> for a compiler whose code generator will accept it.
Only answering the "side effect" part as the rest was answered already.
What a side effect is, is explained in "5.1.2.3". Calling function is only a side effect when the function contains a side effect, such as modifying an object, or a volatile access, or I/O.
As they're freely replaceable through loading, and designed for that, I would strongly suggest that are among the most magical areas of the C standard.
We get a whole section for those in the standard: 7.24.3 Memory management functions
Hell, malloc is allowed to return you _less than you asked for_:
> The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and size less than or equal to the size requested
I read the text as saying the object size can be less or equal to returned memory size.
Anyway, section 7 is library. As you say, replacing through loading is a common thing to do — surely compiler is not free to simply elide external library function at will? This is not C++ after all, it must be sensible
If the function is equivalent to a no-op, and not explicitly marked as volatile for side-effects, it absolutely can elide it. If there is a side-effect in hardware or wider systems like the OS, then it must be marked as volatile. If the code is just code, then a function call that does effectively nothing, will probably become nothing.
That was one of the first optimisations we had, back with Fortran and COBOL. Before C existed - and as B started life as a stripped down Fortran compiler, the history carried through.
The K&R book describes the buddy system for malloc, and how its design makes it suitable for compiler optimisations - including ignoring a write to a pointer that does nothing, because the pointer will no longer be valid.
You are literally scaring me now. I'd understand such things being done when statically linking or running JIT, but for "normal" program which function implementation malloc() will link against is not known during compilation. How can compiler go, like, "eh, I'll assume free(malloc(x)) is NOP and drop it" and not break most existing code?
> but for "normal" program which function implementation malloc() will link against is not known during compilation. How can compiler go, like, "eh, I'll assume free(malloc(x)) is NOP and drop it" and not break most existing code?
I'd suspect that eliding suitable malloc/free pairs would not break most existing code because most existing code simply does not depend on malloc/free doing anything other than and/or beyond what the C standard requires.
How would you propose that eliding free(malloc(x)) would break "most" existing code, anyways?
As an example, user kentonv wrote: "I patched the memory allocator used by the Cloudflare Workers runtime to overwrite all memory with a static byte pattern on free". And compiler would, like, "nah, let's leave all that data on stack".
Or somebody would try to plug in mimalloc/jemalloc or a debug allocator and wonder what's going on.
>As an example, user kentonv wrote: "I patched the memory allocator used by the Cloudflare Workers runtime to overwrite all memory with a static byte pattern on free". And compiler would, like, "nah, let's leave all that data on stack".
Such a program would continue to function as normal; the dirty data would just be left on the stack. If the developer wants to clear that data too, they'd just have to modify the compiler to overwrite the stack just before (or just after) moving the stack pointer.
>Or somebody would try to plug in mimalloc/jemalloc or a debug allocator and wonder what's going on.
Again, that wouldn't be broken. They would see that no dynamic allocations were performed during that particular section. Which would be correct.
I'm a bit skeptical either example is representative of "most" existing software. If anything, the mere existence of __builtin_malloc and its default use should hint that most existing software doesn't care about malloc/free actually being called. That being said...
> As an example, user kentonv wrote: "I patched the memory allocator used by the Cloudflare Workers runtime to overwrite all memory with a static byte pattern on free". And compiler would, like, "nah, let's leave all that data on stack".
Strictly speaking, I don't think eliding malloc/free would "break" those programs because that behavior is there for security if/when something else goes wrong, not as part of the software's regular intended functionality (or at least I sure hope nothing relies on that behavior for proper functioning!).
> Or somebody would try to plug in mimalloc/jemalloc [] and wonder what's going on.
Why would mimalloc/jemalloc/some other general-purpose allocator care that it doesn't have to execute a matching malloc/free pair any more than the default allocator?
I'm not sure debug allocators would care either? If you're trying to debug mismatched malloc/free pairs then the ones the compiler elides are the ones you don't care about anyways since those are the ones that can be statically proven to be "self-contained" and/or correct. If you're gathering statistics then you probably care more about the malloc/free calls that do occur (i.e., the ones that can't be elided), not those that don't.
In any case, if you want to use a malloc/free implementation that promises more than the C standard does (e.g., special byte pattern on free, statistics/debug info tracking, etc.) there's always -fno-builtin-malloc (or memset_explicit if you're lucky enough to be using C23). Of course, the tradeoff is that you give up some potential performance.
Thank you for putting it in a much more correct and understandable language than I could. That is exactly what I am talking about: if you call __builtin_malloc (e.g. via macro definition in the libc header), compiler is free to do whatever it wants. However, calling "malloc" library function should call "malloc" library function, and anything else is unacceptable and a bug. There should be no case where compiler could assume anything about a function it does not see based simply on it's name. Neither malloc nor strlen.
> That is exactly what I am talking about: if you call __builtin_malloc (e.g. via macro definition in the libc header), compiler is free to do whatever it wants. However, calling "malloc" library function should call "malloc" library function, and anything else is unacceptable and a bug.
I think that's an overly narrow reading of the footnote. I don't see an obvious reason why "such names" in the footnote should only cover "some macro names beginning with an underscore" and not also "external identifiers". And if implementations are allowed to define special semantics for "external identifiers", then... well, that's exactly what they did!
In addition, there's still the as-if rule. The semantics of malloc/free are defined by the C standard; if the compiler can deduce that there is no observable difference between a version of the program that calls those and a version that does not, why does it matter that the call is emitted? A function call in and of itself is not a side effect, and since the C standard dictates what malloc/free do the compiler knows their possible side effects.
Furthermore, the addition of memset_explicit and its footnote ("The intention is that the memory store is always performed (i.e. never elided), regardless of optimizations. This is in
contrast to calls to the memset function (7.26.6.1)") implies that eliding calls is in fact acceptable behavior when optimizations are enabled. If eliding calls were not permissible when optimizing then what's the point of memset_explicit?
> There should be no case where compiler could assume anything about a function it does not see based simply on it's name.
Again, external identifiers defined by the C standard are reserved. Reserved external identifiers aren't just for show. From the C89 standard:
> If the program defines an external identifier with the same name as a reserved external identifier, even in a semantically equivalent form, the behavior is undefined.
And from C23:
> If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), the behavior is undefined.
This means that yes, under modern compilers' interpretation of UB compilers can assume things about functions based on their names because modern compilers generally optimize assuming UB does not happen. The compiler does not need to see the function's implementation because it is the function's implementation as far as it is concerned.
Ah yes, N2625 "What we think we reserve". Basically any C program containing variable or function "top", "END", "strict", "member" and so on is non-conforming and subject to undefined behaviour, so they define "potentially reserved" identifiers and as usual compiler vendors go and do the sane right thing.
Nah. Everything I've read about hallucinogens says dose doesn't change effect duration, only intensity. Drugs do affect people differently, so I wouldn't jump straight to saying they're exaggerating.
Also, 12 hours is definitely not short of LSD. I'd say it's the standard duration, with the peak lasting 7 hours. Longer trips can happen, at least to some people, but the default assumption should be about half a day.
definitely not hyperbole. last time i took LSD i dropped at 5pm before going to dinner and ended up at a bread factory 15 miles away at 5am watching them run the big mixers. no idea how i got there just remember walking all night.
I haven't had it happen while reading aloud (since I almost never read aloud), but I've definitely had it happen while reading something new that I hated. I'd end up having to read the same page (or more!) three or four times because I kept zoning out.
My experience has been the exact opposite. Yes, there's literally a lot of information, but so much of it is irrelevant fluff that could be eliminated or trimmed without losing much. I've seen multiple paragraphs of Tolkien, for example, that narratively boil down to "they walk across the field". To be clear, I don't see that as a flaw. The fluff serves to set the mood. But that's different from saying that the text is especially information-dense.
> so much of it is irrelevant fluff that could be eliminated or trimmed without losing much
Are you sure? Or is that just superfluous for the way you’re reading it?
In some cases, it’s overly verbose. But if you’re taking this away from acclaimed authors, consider picking up some literary criticism (fancy words for fan theories). Chances are, there is meaning embedded in what you’re dismissing as fluff.
That's not really "information" in the information-theoretic sense that the other person was using, when it can be rewritten in all manner of different ways while conveying the same overall mood. The densest way to communicate "Sam and Frodo walk across the plain towards Mt. Doom. They're both really tired" is exactly that. All the other words one would write around that core idea would not provide any more specificity to the sentiment, they'd just there to allow the reader to immerse themselves. Unless the information is simply the words themselves, in which case no text is any more entropic than any other.
> Sam and Frodo walk across the plain towards Mt. Doom. They're both really tired.
This does not set a mood and thus does not convey the same information. This removes the information about mood and setting away while keeping only rough plot point in.
The outcome in terms of how reader interpret the situation is massively different. The thing you wrote implies that all they need is to go to sleep an hour sooner and rest, all will be fine.
The thing you're describing that's missing is context, not information. At that point in the plot, the reasons why they couldn't simply take a break wherever they wanted had already been explained, so it didn't need restating. As for mood-setting, I've already addressed that in other replies.
> The densest way to communicate "Sam and Frodo walk across the plain towards Mt. Doom. They're both really tired" is exactly that
Uh, yes. This is press-release speak, optimised for a fourth grader’s reading comprehension.
If, on the other hand, you want to develop the motif of the Unseen—central to Tolkien’s work—the type of tired the characters are and how they’re detecting and addressing it is incredibly germane, interesting and totally lost in your summary.
You’re also describing the first scenes we see through familiar eyes of Mordor. The landscape is an extension of Sauron’s will. The contrast with the developed, organised, albeit crowded cities of men; the arrogance implied in the desolation; et cetera pack information lost in your summary.
The type of tired is "really". What happens is not that there's some additional information that I'm not communicating in that one sentence, but rather that the time it takes you to read "they're both really tired" is not enough for your mind to dwell on the idea and empathize with the characters. Now, if I instead were to write "They're both really tired. They're super tired. Oh man, they're so tired. They're so tired, you've never been this tired in your life", that would be extremely shitty writing, but it would give you time to ruminate on the information.
Extended time is your own proposal, and one you successfully defeated. This is generally called a strawman.
Instead, I propose that the type of tied is informationally and qualitatively distinct. The exhaustion of the weight of the world, internal struggle, amidst a dismal hellscape is different than "really tired".
Great writing can build depth of quality and understanding with the authors intent.
LOTR could be summarized with a sentence. The content is in the detail.
>Extended time is your own proposal, and one you successfully defeated. This is generally called a strawman.
Uh... Huh? So it's my argument, which I've refuted, and therefore it's a strawman? I think you should go get refreshed on informal fallacies. No, what's happening here is that there's a phenomenon that's being discussed -- namely, mood-setting in fictional writing -- and I'm proposing as its mechanism not additional information, but rather additional time. If you want to participate in the discussion you can't dismiss my argument my incorrectly calling it a strawman. You have to explain why it doesn't work as an explanation, like this:
>Instead, I propose that the type of tied is informationally and qualitatively distinct. The exhaustion of the weight of the world, internal struggle, amidst a dismal hellscape is different than "really tired".
Yet, if we were to replace the particular flavor of tiredness with a completely different, equally intense one, it would evoke the exact same empathic feeling on the reader, because the imagination is not precise enough to reproduce other people's feelings with such granularity. Someone can't precisely imagine the difference between the tiredness felt by Conan after 12 hours of turning a mill for the sixth day in a row, and that felt by Frodo. The reader is going to reach that passage and feel that the characters are really tired. That's why such long descriptions don't contain any more meaning; because they can be replaced with something completely different and put the same idea in the reader's mind: "Sam and Frodo are really tired".
>LOTR could be summarized with a sentence. The content is in the detail.
I've already addressed that. If the information is the words themselves and not their meaning, then any English text is equally information-dense. "It's raining" contains a third as much information as "it's raining, it's raining, it's raining", since it contains a third as many words.
> * if I instead were to write "They're both really tired. They're super tired. Oh man, they're so tired. They're so tired, you've never been this tired in your life", that would be extremely shitty writing, but it would give you time to ruminate on the information*
You’ve set up a great question. Why is what you wrote shitty writing while what Tolkien wrote not?
The answer isn’t just variation. If you look at what’s been conveyed in his writing that wasn’t with your repetition, you’ll start unlocking what I suspect you know is there but are having trouble describing.
I do something similar, only keeping my lips shut and moving my tongue and throat as if I was speaking. I find it's an intermediate speed between conversation speed and purely reading with my eyes. I started doing it when I wasn't so good at English to give myself time to understand the text, as well as to practice the mechanics of English speech when I didn't have anyone, but I find keeping me at this pace gives me maximum comprehension. I have a friend who reads much faster than me and he quite often misses points in whatever he's reading. I think he got into that habit from literature, but it's disastrous when reading something more densely packed with information, like technical documentation.
I don't really understand your point in restating this. Someone who says "X should be true" isn't going to be convinced that X should be false by reminding them that X is in fact false.
>GPS et al would be non-functional if everybody could make a jammer.
Then it should be illegal to make a GPS jammer. Making it illegal to reprogram a GPS receiver in any way is unnecessarily broad.
GPS is a bad example, but there are things that pose a physical threat to others that we maybe shouldn't tinker with. Like I think some modern cars are fly-by-wire, so you could stick the accelerator open and disable the breaks and steering. If it's also push-to-start, that's probably not physically connected to the ignition either.
It would be difficult to catch in an inspection if you could reprogram the OEM parts.
I don't care about closed-course cars, though. Do whatever you want to your track/drag car, but cars on the highway should probably have stock software for functional parts.
> Like I think some modern cars are fly-by-wire, so you could stick the accelerator open and disable the breaks and steering.
Essentially all passenger cars use physical/hydraulic connections for the steering and brakes. The computer can activate the brakes, not disable the pedal from working.
But also, this argument is absurd. What if someone could reprogram your computer to make the brakes not work? They could also cut the brake lines or run you off the road. Which is why attempted murder is illegal and you don't need "programming a computer" to be illegal.
> It would be difficult to catch in an inspection if you could reprogram the OEM parts.
People already do this. There are also schmucks who make things like straight-through "catalytic converters" that internally bypass the catalyst for the main exhaust flow to improve performance while putting a mini-catalyst right in front of the oxygen sensor to fool the computer. You'd basically have to remove the catalytic converter and inspect the inside of it to catch them, or test the car on a dyno using an external exhaust probe, which are the same things that would catch someone reprogramming the computer.
In practice those people often don't get caught and the better solution is to go after the people selling those things rather than the people buying them anyway.
> GPS is a bad example, but there are things that pose a physical threat to others that we maybe shouldn't tinker with. Like I think some modern cars are fly-by-wire, so you could stick the accelerator open and disable the breaks and steering. If it's also push-to-start, that's probably not physically connected to the ignition either.
I'm not seeing an argument here.
Cars have posed a physical threat to humans ever since they were invented, and yet the owners could do whatever the hell they wanted as long as the car still behaved legally when tested[1].
Aftermarket brakes (note spelling!), aftermarket steering wheels, aftermarket accelerator pedals (which can stick!), aftermarket suspensions - all legal. Aftermarket air filters, fuel injectors and pumps, exhausts - all legal. Hell, even additions, like forced induction (super/turbo chargers), cold air intake systems, lights, transmission coolers, etc are perfectly fine.
You just have to pass the tests, that's all.
I want to know why it is suddenly so important to remove the owners right to repair.
After all, it's only been quite recent that replacement aftermarket ECUs for engine control were made illegal under certain circumstances[2], and that's only a a few special jurisdictions.
What you are proposing is the automakers wet dream come true - they can effectively disable the car by bricking it after X years, and will legally prevent you from getting it running again even if you had the technical knowhow to do so!
---------------------------
[1] Like with emissions. Or brakes (note spelling!)
[2] Reprogramming the existing one is still legal, though, you just have to ensure you pass the emissions test.
>you could stick the accelerator open and disable the breaks and steering
This is silly. Prohibiting modifying car firmware because it would enable some methods of sabotage is like prohibiting making sledgehammers because someone might use one to bludgeon someone, when murder is already a crime to begin with.
Uhh... Is this the '90s? People don't type in IP addresses (or phone numbers, back in the day) to connect with other people anymore. They connect to a common, publicly reachable server that deals with peers being behind NAT.
reply