The obvious next step is to crawl the whole database of vulnerable Kia cars and create a "ride share" app that shows you the nearest Kia and unlocks it for you.
I wonder if you could construct a hash collision for high pagerank sites in the google (or Bing) index. You would need to know what hash algorithm google uses to store URLs. This is assuming that they hash the URLs for their indexing. Which surely they do. MD5 and SHA1 existed when google was founded, but hash collisions weren't a big concern until later IIRC. You'd want a fast algorithm because you're having to run your hashing algorithm on every URL you encounter on every page, and that adds up quickly.
The max legal length of URLS is 2048, but I wouldn't be surprised if there aren't plenty of non-compliant URLs longer than that in the wild. If you were limited to 2048 characters, and a valid URL format, I suspect it would be hard if not impossible to build a URL with the same MD5 of an arbitrary high ranking URL like "https://nytimes.com/" But what if you just wanted to piggy back the pagerank of any mid to high rank site? Is there a URL in the top million ranked URLs you could MD5 hash collide?
I doubt google would use a URL hash as strong and as slow as MD5. Maybe Page and Brin weren't even thinking about cryptographic hashes, and just a good mixing function.
"Usenet is like a herd of performing elephants with diarrhea -- massive, difficult to redirect, awe-inspiring, entertaining, and a source of mind-boggling amounts of excrement when you least expect it. " -spaf
What if we could make every car $5-10k more expensive instead?
</satire>
I once thought that using AI to make all cars self driving might be the key to making pedestrians and cyclists safe. Self driving cars are playing a game of Russian Roulette. The systems will get it wrong occasionally, with LIDAR or without. Not if, but when. Whether or not someone dies depends on the situation.
Search traffic has always been mostly automated spam bots.
Even back in the Open Directory Days when we powered part of search.netscape.com I estimated 80+% of all search traffic was automated. At least most of it self-identified with the same Java useragent.
Later when working Topix, despite being a news search engine, most traffic was bot traffic. Most included the word “mortgage” in the query. Topix specialized in localized content, and that was very popular for SEO scrapers.
Lastly at Blekko, I estimate 90+% of traffic was automated. By then maybe half or more learned to change the user agent. Most used HTTP/1.0, a dead giveaway as no browser still uses 1.0. This was a major aspect in Blekko's load shedding strategy. If the servers started to get overloaded, we'd start bouncing suspected bot traffic to a redirect that would show in the logs. If there was a human with a modern browser running javascript on the other end, would get redirect to a link that wouldn't get bounced. I would check the logs weekly to see if any humans got caught. None ever did. This was a huge monetary savings, you only need 1/10th the servers if you can safely ignore the bots.
Often it's endless repetition of the same keywords in a random order with a place name appended, or prepended, or inserted. over and over. Often variations on known monetizatable SEO keywords. However, much of it doesn't make any sense.
I don't have any insight into Google's numbers but I would conservatively estimate 95% or more of all their queries are automated bots and not humans. And the level of spy-vs-spy going on for Google CPU resources vs SEO bots is probably pretty evolved by now. I stopped tracking many years ago when Google switched to densely packed obfuscated javascript for page renders. Maybe this is part of why automated queries are so high across the web, maybe google is too hard to crack for most.
I was introduced to this and other calendar quirks by Professor Edward Reingold when taking introduction to CS at UIUC. One of our "machine problems" (AKA programming assignments) was to write a date converter that could convert between Gregorian, Julian, and the French Revolutionary calendars.
Dates from 1752 were in the test set.
The French Revolutionary Calendar was interesting. Ten days in the week, 3 weeks per month, with a extra "bonus" month at the end of the year with 5 (or 6) days. One reason it didn't last is that despite the change in the week length, workers only got 2 days off per week.
This is very disappointing. I would love to hear from user crhulls https://news.ycombinator.com/user?id=crhulls the CEO Life360 (or so claimed, I can't verify). Too bad Hacker News doesn't have a notify on @ mentions. Then again, not being discord is a feature not a bug.
I've been using emacs as my primary editor since 1989. It has for that entire time been a PITA to configure. My first customization was to map backspace to ^H and map the insert key to 'nil.
I used to dedicate a couple days every January to investigate new emacs tools. Read about the latest features or new modes, often from my org-mode TODO list where I bookmarked them. I have learned to never update emacs mid-project as I've on multiple occasions shattered my emacs config updating versions or moving to a new distros. MacOS brew install vs .dmg install? Aquaemacs? DoomEmacs? Oh, hello the malpa repo URL changed and is https only now.
VSCode has a healthy extension marketplace, something emacs should adopt.
elisp is dead. Not because it is dead, or deserves to be dead, but because everyone "believes" it dead. Same goes for Perl.
I love emacs, it has been a rock my entire programming life, but it's a time suck to configure. I know there are some who have created a Sistine Chapel in their .emacs.d, and I'm jealous. There's a fine balance between spending time and effort optimizing and sharpening your tools and emacs is deep on the wrong side of the line for me.
I don't want emacs to ever die. But come on, if you're losing to vim in popularity, you are already dead.
This new version of the Fisher-Price Record Player is heartbreaking. I learned so much from trying to understand how it worked. Concepts like stored energy: experimenting with trying to over-wind, under-wide, a few turns, many turns, slowly adding pressure to the winding knob until it would start playing and try to maintain just enough pressure to play. Physically slowing and speeding up the turntable to change to the tempo. Trying to intentionally misaligning the head to play out of tune. Turning it on it's side, upside down, trying to peek at the teeth on the head and manually play individual notes. All at an age before I could read. That toy was indestructible, because if it weren't I would have torn it down to individual components (just like my very expensive 6 million dollar man action figure, to the great chagrin of my parents). It wouldn't be until much later I'd have to tools to dissemble one, and by then I was taking apart real record plays.
This toy is a good analog for a real record player and with grooves that move a needle and play sound encoded on the disk. Leading to understanding of sound waves.
This new toy is a mix of new and old tech. How can a per-literate child be expected to decipher binary encodings and how they map to individual songs? What deeper understanding of how things work are within the grasp of a child that cannot yet use a screwdriver, wire cutters, and a volt meter?
This new toy is boring. Once you learn how to turn it on, it can have no appeal to a child exposed to much better music players all around them: cell phones, iPads, computers, tvs. This is just a piece of plastic and e-waste destined for the landfill, purchased by some sentimental old timer who has fond memories of the original F-P record player.
Of course I had to test this by drawing an Interrobang: ‽
It got it right. My first drawing didn't have interrobang at the top of the suggestion list, because I didn't have the top closed. So there is some bias from the font it was trained on.
I worked at IBM a few years ago. When I started we were had to use Notes for email, not long after we got migrated to Verse (IBM's webmail system). Verse was better than Notes (damning with faint praise).
One day I wondered why Verse took so long to start, i.e. time to first render of emails. So I profiled the startup using a browser performance profiler. It didn't take me long to discover there was a sleep(5) in one of the Javascript files. Every employee was subjected to a sleep(5) for every single login. Of course for security reasons your email session timed out every 12 hours or so, meaning that every employee is logging into email at least once a work day. Some napkin math: at the time IBM had almost 400k employees, so that's 555 hours per day of wasted employee time. Or 138,888 hours per year of wasted employee time. To be fair some large number of IBMers may not have had jobs that subjected them to Verse.
I just advertise both Pi-Holes via DHCP and when I configure manual DNS settings. The primary DNS gets the vast majority of the DNS traffic, about 150 requests/minute and the secondary gets about 10 requests/minute (mostly from a single device).
Both piholes are on different UPS power, different switches, in different locations. In theory the lights will go out on the main UPS and switch first (it draws more power), but this configuration did save me once.