Re: Tried it and...
I'm guessing your ISP has some sort of IPv6 routing issue. Where I live YouTube, Netflix etc all run well on IPv6.
Of course, if everyone just disables it instead of complaining/ debugging it will never get fixed.
464 publicly visible posts • joined 4 Apr 2007
"you'd not have ipv6 with out ipv4, ipv4 is not a blocker for ipv6, IPv6 is the blocker for IPv6."
I literally had the largest ISP in Canada (Bell Canada) tell me they had so many IPv4 blocks they just didn't need IPv6. When I thought about the last time I worked for a smaller ISP, Bell had been using IPv4 blocks to sweeten the deal and lock in upstream contracts. They literally rent out IPv4 blocks.
As long as they are making money off IPv4 scarcity, there is an active reason for them not to upgrade and that BELL is the main reason Canada is stuck oat 41% IPv6 adoption.
The best part is, they have it running great on their mobile offerings where they had no other choice.
You don't need NAT on IPv6 to retain IPv4 addresses on your LAN, dual stack handles that just fine.
Endpoint devices are not in any way stopping IPv6 adoption so we don't need translation at the router. Linux, Windows, Mac, Android and iphone all support IPv6 out of the box and have for quite a few years and In my experience, as soon as IPv6 is enabled on the router, every device behind it autodetects and uses it.
For the past 15 years or so, the main barrier to adoption has been internet providers.
'A week later, I learned that they were still using Office - unregistered - because LibreOffice was "too complicated".'
I bet they didn't even try LibreOffice.
I have redirected more than a few people who come to me asking about either their trial office subscription expiring to Libre Office or where to find an affordable Office for their new PC. These people are not what I would refer to as "technical" and I have had no complaints.
My trick is to always hit whatever button gets me a live operator and then tell them off. If everyone did that, it would throw the economics of the scam operations on it's head since they use the robocall to spam as many numbers as possible without having to expensive humans and that wouldn't be possible anymore.
That's easy. Micro USB cables in particular don't like being plugged and unplugged on a regular basis. I considered the cables I used to charge my phone as disposable and kept spares around since they rarely lasted more than two or thee months.
In one case, I stopped buying long cables and saved money by using a USB extension cable with a short micro USB on the end of it that I changed regularly.
See now you've changed your error message. The previous message you added was almost exactly the one gcc gives when you cast between incompatible types.
At any rate, with that new message, I do hope you were manually adding the null at the end of the string after you copied it.
"So, I don't have -Werror, but I do have -Wall. And note that, annoyingly, -Wall with gcc does not enable *all* warnings. I haven't looked at them for a while, but mine are currently:"
I think the idea is that GCC doesn't break things with changes to the warnings. I have a script that gets the GCC version and enables all warnings for that version, passing that variable back to make.
I really wish GCC would have a -Warnings=GCC_version or something so I can just tell it to enable everything.
I would be interested to see the code you used for your copy because usually that warning indicates you are casting something to an incompatible data type and GCC thinks information is being lost in the conversion. Nothing to do with how much of the string you care copying. You only think the warning is stupid because you misunderstand the nature of the warning.
Years ago I made this exact commit to one of my projects along with a set of annotations for all of the functions that used format strings. The other programmer threw a hissyfit and turned it all off again complaining about the fact that he didn't have time for all of that. A couple weeks later we try it on some nice new 64 bit servers and his code couldn't even last 30 seconds without a crash.
Years later, he quit/got fired (depending on which side you ask) and I got stuck maintaining his code. I ignored the large bug list while enabling a set of warnings/ fixing them, in a loop for a few weeks. When the code was retested, 95% of the bugs were gone. His logic was fine and he could have saved himself years of effort had he fixed the warnings in the first place.
Here is a simple unit file I used to re enable rc.local on my PC.
The only other thing you could need is a "Requires=" under "[unit]" to load it after some needed dependency.
[Unit]
Description=/etc/rc.local
ConditionPathExists=/etc/rc.local
[Service]
Type=forking
ExecStart=/etc/rc.local
[Install]
WantedBy=multi-user.target
That's the odd thing for me, I have installed pretty much every version of Debian released in the past 18 years and I've never had it fail to ask me to setup a network interface with IPv4. Mind you, if you assign both IPv4 and IPV6 addresses it will prefer IPv6.
I fail to see how systemd could be harder in your case. The most familiar implementation would be to load a shell script from a minimal unit file that only specifies the dependencies and startup script. For me it has been the opposite, I have server and home network configs that I can get working more easily than before. Getting filesystems on FiberChannel or ISCSI is much easier now. Even in my home setup, I can have certain software not load until he CIFS mounts are in place with just a short unit file.
I don't understand what is so wrong with Makefiles? They are great when you want to build on a machine that isn't yours. For example, I code on my PC, but test on a sever (or other people compile onsite) Makefiles are great for dependency checking.
For example, My Makefiles let the user know each step of the process with short descriptive messages, combine the source from the src folder and the includes from that folder (and sub folders) it also only re compiles only the needed source files if I make a header change.
Admittedly there is some dark magic in the regex to make some of that happen but once written, it's done. I generally just reuse the Makefile with minor modifications on new projects.
"I did ask about window managers, Gnome and the like rather than Linux itself. How do they take touch-screen inputs and translate them into HID inputs like key presses and mouse movements, click and drag etc.? Are they functional with touch out-of-the-box or does it require tweaks and configuration of the installation?"
Years ago I worked on POS systems and it was a huge pain. Every POS had to be calibrated and the Linux commands to get that working were annoying (it didn't help that the POS manufacturer couldn't even be bothered to orient the touchscreens the same way each time) so it was with much nervousness that I got a touchscreen laptop 2 years ago.
I hunted and hunted for documentation and couldn't find it, so I tried catting the input device and touched the screen to see what would happen. The mouse jumped to my finger position. It seems every Linux distro for the past few years just enables touch by default.
"They are very insecure for the simple reason that nobody ever bothered securing them. Unless you consider a simple key lock on a street box that is accessible by anybody to be secure."
Indeed, and quite often all lights in a given region will have the same key. I had a friend in high school who found one of the keys in a "hidden" box and started handing out copies to all of his friends.
"The thing is, Musk wails about "short sellers" all the frigging time. Anytime Tesla gets any kind of not-totally-rave press, it's malicious lies planted by short sellers. It's getting old."
To be fair, they tend not to let up for even a moment. Every possible bit of bad news and Tesla is doomed. Last year we had someone cry about a "demand cliff" in California, they turned out to be very wrong. Now this year the exact same person is claiming there is a demand cliff in California and he made sure he got quoted by all of the media. Never mind that Tesla is back ordered 5 weeks and prioritized deliveries to make sure customers in the Netherlands didn't lose out on rebates before they expired. Some of the other hit pieces from Dec/Jan: "excluding the Netherlands, Tesla sales are down."
So now we have a guy, who trolled the NHTSA database for things to complain about. Most of these were already investigated.. One of the highlighted complaints is something the car can't physically do for regulatory and safety reasons. Another case is where the data recovered from the car showed no break press and 45 degrees on the accelerator when the "unexpected acceleration" happened. And of course, he goes out and contacts the media and of course, he just happens to have a short position in Tesla. Why exactly should we take him at his word?
Somewhere short selling became a game to drive the stock down and it's not just Tesla that has suffered from this.
The flaw in your reasoning, is that this petition was filed by Brian Sparks who has self identified as having a short position in Tesla. He claims to have heard about the problem but doesn't seem to own a Tesla himself. The petition covers 2013 - 2019 (6 years) and complains about 127 issues. That's 21 complaints a year, hardly a widespread problem even if all of the complaints turn out to be true.
To top it off, one of the complaints involves the Tesla not allowing the driver to override the steering wheel, which is something that the steering assist is designed to not be strong enough to do.
In my view, this short seller is being squeezed by the latest short burn and is trying to recover his losses.
"Well they **COULD** have dedicated one (1) IPv4 address for use as a flag that a 128 bit address will be found elsewhere in the header. That's probably not the best answer, but it's what pops immediately to mind. Truth is surely that the IPv6 designers thought (incorrectly) that they were dealing with a captive audience that had no choice but to follow the IPv6 game plan."
So adding a branch to the middle of packet hadling code forever. Congrats. Your plan slows down packet processing. A branch may not seem like much, but consider what happens with a device is used for routing and/or exists on a high speed interface. Those branches add up.
The IPv6 designers knew the transition was going to be painful and there was no other way around it (you can even read their logic if you bothered to look) so they went out of their way to make it only needed once. You could try looking it up yourself instead of assuming the worst possible motives for people you haven't met.
"My suggestion. IPv6 people should recognize that they screwed up. Cancel the "transition" Come up with something serious and effective to tame IoT problem (which they didn't cause, but truly must not enable). Then design a new protocol compatible with both IPv4 and IPv6. And give a lot of thought to ease of implementation this time."
Please explain how to extend a fixed 32 bit header field without slowing down packet processing or introducing incompatibilities.