Chrome has a browser extension API which allows plugins to access all cookies, but its use is considered suspicious and a red flag; an extension which uses it would generally get caught during initial review. However, Chrome extensions are also allowed to “hotload” portions of their own code/scripts from external 3rd party servers.
So an extension will seem benign when it initially gets checked by Google as part of becoming part of its submission to the Chrome Store. Then, later, the external “3rd party” script that is hosted remotely will get replaced with a different, malicious script. The malicious extension carries on stealing cookies, credentials, and fingerprints until someone reverse engineers it and reports it to Google.
Google will not always recognize the issue immediately because the 3rd-party malicious code is not strictly “part of” the extension so there’s a bit of a song and dance while the person who reversed it convinces Googles reviewers that “yes, this really is actually malicious, you need to analyze the third party code that loads later” and then Google eventually takes it down after a semi-involved back-and-forth where extensive documentation and video walk-throughs are provided by the exasperated white-hat Good Samaritan.
Revisiting this. Isn't it a bit of a red herring to enquire about the number of 2-faces that an n-simplex has? It still only has n+1 vertices. A 768-simplex may have 75.5 million faces but it will still only have 769 vertices which completely define the shape. So why would I expect a large number of the other >90% of the 10,000 samples I have to lie on the surface, rather than inside the interior volume?
To be more direct, what's the specific relevance of bringing up the number of 2-faces that an n-simplex has?
> The real problem is that in dimensions that high, the point set probably already is the hull and all this is a zero signal gain operation.
Well, if I have 10,000 samples of a 768-dimension volume, most of those points will probably be inside the volume, and not per se a vertex of the hull.
I’m very comfortable rolling my own solution, so thank you for pointing me to Jarvis’ algorithm!
I've been trying to use convex hulls to explore ML embedding spaces. However, the dimensionality (768+ dimensions) seems to crash established options like QHull[0], even with 64GB RAM (and 16 CPU cores, albeit libqhull is not multi-threaded).
Are there more appropriate algorithms for finding convex hulls where dimensions are ~768? Or any parallelized / GPU-optimized options that I should look into?
Check out TIZIP SuperSeal zipper -- it was used on some "dry suits" I wear for offshore sailboat racing in cold-water environments and is truly water-proof. It's advertised to be water-proof up to 700 millibar of pressure differential, which is equivalent to 23 feet of water depth. This zipper does require maintenance in the form of regular lubrication using, for example, a food-grade silicone grease/lubricant like the ones used for slushie/daiquiri machines.
I've looked into getting it worked into bags from Montrose Rope and Sail in Scotland when I worked in offshore industrial environments, but they don't have the equipment to do the "vinyl welding" necessary so you'd have to buy the bag without zippers and then find someone else who could do that welding.
> Spending 8k-ish to build a product demo for my friends rich uncle is too uphill for me to risk.
That’s something I could potentially fund. No equity, just pro-bono / repay if it works out. Feel free to reach out and chat if it’s a dream you believe in.
Could you pirate the database, then hide behind the fifth amendment to not reveal that you're a pirate while simultaneously asserting that you never agreed to any EULA? I'm not sure what the legal rights are here.
I'm certain someone in say, China or Russia, could pirate the database and run benchmarks on it with no repercussions. Surprising that this isn't a business model for an overseas technology analyst firm.
For web scraping specifically, I’ve developed key parts of commercial systems to automatically bypass reCAPTCHA, Arkose Labs (Fun Captcha), etc.
If someone dedicated themselves to it, there’s a lot more that these solutions could be doing to distinguish between humans and bots, but it requires true specialized talent and larger expenses.
Also, for a handful of the companies which make the most popular captcha solutions, I don’t think the incentives align properly to fully segregate human and bot traffic at this time.
I think we’re still very much still picking at the very lowest hanging fruit, both for anti-bot countermeasures and anti-anti-bot (counter-countermeasures).
Personally I believe this will finally accelerate once AI’s can play computer games via a camera, keyboard, and mouse. And when successors GPT-3 / PaLM can participate well in niche discussion forums like HackerNews or the Discord server for Rust.
Until then it’s mainly a cost filter or confidence modification. As long as enough bots are blocked so that the ones which remain are technically competent enough to not stress the servers, most companies don’t care. And as long as the businesses deploying reCAPTCHA are reasonably confident that most of the views they get are humans (even if that belief is false), Google doesn’t have a strong incentive to improve the system.
Reddit doesn’t seem to care much either. As long as the bots which participate are “good enough”, it drives engagement metrics and increases revenue.
Your service helped me immensely when I was getting started with machine learning, but had no budget and just a laptop. For me, everything “just worked”, and I learned a ton about Docker and created my own system to handle the ephemeral nature of the computing systems by automatically backing up training checkpoints, programmatically finding the next best “deal”/“bid” and resuming the training on a different instance.
Was very very cool, and I generally recommend it to anyone I come across who has modest needs (<25 GPUs).
I did find the throughout was not always accurate at the time. This was about 2 years ago. It was fairly frequent that a listing would say “300” to “1000” Mbps Up+Down, but would actually get an order of magnitude less to any of the big cloud services (GCP, AWS, etc). It wasn’t important to me that the speed was low, but it was important that it didn’t match what was “advertised”. For certain workloads I would have gladly paid more for higher throughput but that’s not really an option when the listings couldn’t be fully trusted.
I also heard there may be some opportunities to market your technology/platform for “on-prem”, “on-demand” GPU clouds for large enterprises so that a pool of corporate GPUs could be efficiently used and accurately billed to a variety of internal stakeholders. Could improve asset utilization for capital intensive on premise GPU’s.
To be pedantic, there is a built-in 16kB ROM starting at address 0x00000000 with RPi's open-source BootROM burned into it at the time the silicon is manufactured. There's no publicly-known way to write to this. It's technically "non-volatile storage", but it's not useful to anyone other than RaspberryPi/TSMC.
In fairness, many of these will end up in consumers hands shortly after a bit of additional value-add. On the bare-bones side, that's things like JLC PCB stocking them for pro-hobbyists to get custom low-volume PCB's made with them. A bit higher up the food chain, mere tinkerers could expect to find more form factors of fully ready-to-use boards available at microcenter/ailexpess/amazon/sparkfun/etc.
For mere hobbyists, adding network connectivity will be the biggest hurdle for most of their projects, and hopefully some of the microcenter (et. al) options will provide options. It doesn't have any on-board solutions for this (unlike, say an STM32F207 which has low-level ethernet capability that just needs to be broken out to a physical interface).
Generally though I think most networking solutions for the RP2040 will max out at 66.5Mbps max theoretical throughput, because this is the limitation of SPI interface when the RP2040 has its system clock set to 133MHz (perhaps a bit more throughput is possible with overclocking).
Note that the dual Cortex M0+ cores have some (serious) limitations, namely: No floating point math (although the compilers usually do a pretty decent job of letting hobbyists forget this!). No Embedded Trace Macrocell or Program Trace Macrocell for debugging (only Micro Trace Buffer). Only 4 breakpoints and 2 hardware watchpoints.
It's important to truly understand the hardware limitations as much as possible to avoid issues caused by things like interrupt priority inversion[0].
This could be incredible for us. We've been facing the same shortages of various STM32 ARM MCU's as everyone else, but most (all?) of our designs could theoretically be replaced with RP2040's -- and the dual core M0+ could provide some key performance/latency guarantees that single, more powerful cores like the M3 might not be able to.
Whether it's worth the engineering time to port the code and re-design PCB's is...dubious, at our low volumes. But any option that attempts to promise to "beat" the contemporary supply chain challenges would be strongly considered. The long-term price savings are attractive as well (~$10 less per board over what we currently use -- which admittedly was optimized for development convenience, not per-unit cost).
I have a lot of experience in the industrial SCADA domain. I largely agree with you, but I will say that historically most installations have had all the relevant source code available to them, or owned by them.
In most cases, the limiting factors for lifespan were:
1) Inability to get replacement hardware
2) Inability to find anyone who can understand the source code.
There's really no way around issue #1. Having the software source doesn't really help that much because most of the time they'll use "migrations" every 10-15 years to rewrite the code using updated understanding of how they want the plant to work. Kicking off a SCADA upgrade is used as a wonderful convenient excuse to drive a lot of meetings/paperwork processes to define "How can we improve safety, improve reliability, make life easier for the human operators, etc?"
Nowadays, the thing time-limiting many SCADA installations are licensing for Windows LTSB and PLC/DCS vendor software. Often times newer versions will require new Dell/HPE servers for compatibility. It's expensive, but also not expensive enough to focus on changing.
The main point is that while licensing artificially limits "longevity" of a machine, closed-source does not. Instead, unavailable replacement hardware limits "longevity" more than "closed source" does.
This is super cool! I started toying around with pretty much the exact same concept at the same time as this (2019 - https://github.com/rckoepke/dog_training_NN/blob/master/DogT...) but realized I needed significantly more skills in embedded and mechanical areas to realize my vision.
I completely agree with targeting use at shelters and dayboarding...if this works at all for untrained dogs it will probably only work for under-stimulated dogs. Shelters are a rich environment for finding under-stimulated dogs.
I wish I could say the concept won't work in people's homes but honestly so many pets are probably also lacking sufficient meaningful interaction with their owners.
Great timing. I'm looking for solutions to run Siemens Simatic PDM without being a local admin. Installing it with temporary admin rights seems to silently fail.
I'm also trying to use libpcap and USBPcap without local admin. They request UAC every time I open Wireshark to start a new capture session. (Needed for debugging raw Ethernet and serial stacks)
If you have any tips for either of these I am all ears!
See also RENEW, the “world’s first fully programmable and open-source Massive-MIMO Platform” which may help to provide open source hardware and firmware for high-end installations. https://news.ycombinator.com/item?id=24026416
The UI seems very thoughtful, it's clearly a high-quality effort! I'm pleasantly surprised by how intuitive it appears at first glance. It's one of a vanishingly few examples of a "modern"-looking UI with high information density and minimal whitespace.
Your team also picked the right hero image for the homepage, and I love that it opens up into a YouTube video. It did take me awhile to realize that it opens into a video though - the bright purple "Play Demo Video" button was treated as spam by my brain. I believe that's because the UI in the image is very busy, so there are a lot of higher-priority details that I can focus on/explore until my internal "look elsewhere on the site" timer expires and I scroll off the hero image.
It feels like this does deserve more attention. I suspect people who aren't currently working with self-propelled robots may be skipping this as they aren't able to envision where they'd use it. I'd enjoy exploring it with something like this starter kit, though: https://foxglove.dev/blog/building-and-visualizing-your-firs...
So an extension will seem benign when it initially gets checked by Google as part of becoming part of its submission to the Chrome Store. Then, later, the external “3rd party” script that is hosted remotely will get replaced with a different, malicious script. The malicious extension carries on stealing cookies, credentials, and fingerprints until someone reverse engineers it and reports it to Google.
Google will not always recognize the issue immediately because the 3rd-party malicious code is not strictly “part of” the extension so there’s a bit of a song and dance while the person who reversed it convinces Googles reviewers that “yes, this really is actually malicious, you need to analyze the third party code that loads later” and then Google eventually takes it down after a semi-involved back-and-forth where extensive documentation and video walk-throughs are provided by the exasperated white-hat Good Samaritan.