bias disclosure: i used to do Android dev and kinda hate the browser personally.
i don’t get this take. “Web browser is sandbox by default”. sure, it has to do the rail grind with a rake to access system calls, but in a modern system apps are also sandboxed, especially on a smartphone or when downloaded with a managed app service. the OS gives you the ability to specify permissions, although to what degree depends on your provider. your browser _obviously_ also has the permissions you’re talking about. and now we have introduced yet more vectors in the form of cookies where web _applications_ can track activity _between applications_ with that just kinda being part of the spec, and it totally neuters the protections that the OS gives you because once you configure Firefox to get your location for Open Maps, now you’ve totally given control to your location permissions for _all web apps_ to yet another corporate driven point of failure.
don’t even get me started on the UI mess.
my tinfoil hat theory is that the browser is pushed by mostly bad actors trying to get data, while anyone providing a real user experience has a nice native app.
i’m seeing this at my corporate software job now. that service that you used to have security and product approval for to even read their Swagger doc has an MCP server you can install with 2 clicks.
the idea of one language to rule them all is very compelling. it’s been promised a lot, and now everyone hates Java.
but the truth is that Rust is not meant for everything. UI is an abstraction layer that is very human and dynamic. and i can come and say, “well, we can hide that dynamism with clever graph composition tricks” à la Elm, React, Compose, etc, but the machinery that you have to build for even the simplest button widget in almost every Rust UI toolkit is a mess of punctuation, with things like lifetimes and weird state management systems. you end up building a runtime when what you want is just the UI. that’s what higher level languages were made for. of course data science could be done in Rust as well, but is the lifetime of the file handle you’re trying to open really what you’re worried about when doing data analysis?
i think Rust has a future in the UI/graphics engine space, but you have to be pretty stubborn to use it for your front end.
> also it is amazing to me that shells still exist in more-or-less the same form. dear god can I just get a terminal that runs something like Python directly?
i’ve been maining `nushell` for about 1.5 years now, and it’s basically this. a real programming language that is designed as a command runner and output parser. i have a ton of scripts that parse output from common commands like `git` and facilitate a ton of shell-based workflows: https://github.com/covercash2/dotfiles/tree/main/nuenv
well, it’s a few things. a lot of it comes down to reading structured data and scripting. i will often stream logs from k8s or when running a service locally that outputs JSON, and nushell can parse the logs for readability or to find a particular field. i mean, that’s nothing jq couldn’t do. but having an integrated experience based more on readability makes things nice.
also when i say scripting i mean actual real functions. you can define a command complete with parsed documented arguments as if you’re using argparse or clap, and it also supports completions. so when i go to sign into the company VPN i have a lil function that grabs my credentials and takes an argument that is one of several providers my company uses, which i can autocomplete with tab because i’ve written a simple completion helper (literally a function that returns a list). it’s documentation as code, and i push all these helpers up to my company git repo so when someone asks me how to do something i have workable readable examples.
if you’ve ever wanted a real programming language (like Python) as your shell, i think this is worth a shot.
nushell does this by default, sort of. it will show you autocompletes that are relevant to the current directory and will fallback to history more generally.
i’m a huge nushell fan. if you can stand a non POSIX shell, it’s great for working with any kind of structured data and has a sane mostly FP scripting language
hard disagree. i had an experience just this morning looking for some pictures from an event i participated in, and the infinite scrolling was absolutely infuriating. they didn't have an index to filter on, and when i clicked on a picture to download it and navigated back, it took me to the top of the page. i had to scroll through about a dozen loading indicators to get back to where i was. sure, this was a bad implementation, but adding it to every single list of results on the web is asinine trend chasing and bad UX.
as mentioned in another comment, "scale" is not just horizontal, it's vertical as well. with millions of products (UPCs) across different visual tolerances it's hard to generalize. your annotation method is indeed more efficient than a multistep "go take a bunch of pictures and upload them to our severs for annotators" but is still costly in terms of stakeholder buy-in, R&D, hardware costs, and indeed labor. if you can scope your verticals such that you only have, say, 1000 products the problem become feasible, but once you start to scale to an actual grocery store or bodega with ever-shifting visual data requirements the problem doesn't scale well. add in the detail that every store moves merchandise at different rates or has localized merchandise then the problem becomes even more complex.
the simulated data also becomes an issue of cost. we have to produce a realistic (at least according to the model) digital twin that doesn't interfere too much with real data, and measuring that difference is important when you're measuring the difference between Lay's and Lay's Low Sodium.
i'm not saying it's unsolvable. it's just a difficult problem
right, that's how it starts. but the improvements in methodology simply aren't there as the ML sector has been laser focused on generality in modeling (GenAI as it's affectionately known). "at scale" doesn't just mean more stores; it means more products and thus more annotation. how many UPCs do you figure there are in a given Target or Whole Foods? i assure you it's in the millions.
one advantages of the Amazon Go initiative is a smaller scope of products.
i mean, labor cost (as in in-store labor) is the target for this cost optimization. unfortunately for the time being labor cost is not as significant as the other costs associated with annotation and dataset curation. technology costs are not really significant if this can be pulled off at scale.
in-store employees know where things are supposed to be and why, if at all, items are "misplaced" according to the modular design
a big problem in the space is that products that look very similar will be clustered in the same section. large models are very good at generalizing, so they may be more attuned to "this is a Christmas thing", but they won't know that it should be classified as the same UPC as the thing that was in that spot yesterday without you specifically telling it to. how would it know it's not a misplaced product or a random piece of trash? (you won't believe the things you find on store shelves once you start looking) you can definitely speed up your annotation time with something like SAM[1], but it will never know without training or context that it's the same product but Christmas (ie it resolves to the same UPC).
there's no way they were turning a profit. they definitely missed stuff all the time even with a ton of sensors. and sensors aren't the only cost. annotation is by far the most costly operational expense. new product? needs several annotated photos and recalibrated weight sensors. merchant decides to put Christmas branding on the same UPC? now all your vision models are poisoned for that product. it needs to be re-annotated for the month and a half it exists and the models need to be swapped out once inventory changes over again. as long as merchants are redesigning products (always) your datasets will be in a constant state of decay. even if your vision sensors are stationary and know the modular design up front, you still need to be able to somewhat generalize in case things get misplaced (big problem for weight sensors) or the camera gets bumped.
between dataset management, technology costs, research costs, rote operational costs, etc this is a very expensive problem to solve. and large models with a ton of parameters are little help; they may lower annotation costs a bit but will increase the cost of compute.
once i really dug into this problem i saw Amazon Go's Just Walk Out for what it really was: a marketing stunt
i don’t get this take. “Web browser is sandbox by default”. sure, it has to do the rail grind with a rake to access system calls, but in a modern system apps are also sandboxed, especially on a smartphone or when downloaded with a managed app service. the OS gives you the ability to specify permissions, although to what degree depends on your provider. your browser _obviously_ also has the permissions you’re talking about. and now we have introduced yet more vectors in the form of cookies where web _applications_ can track activity _between applications_ with that just kinda being part of the spec, and it totally neuters the protections that the OS gives you because once you configure Firefox to get your location for Open Maps, now you’ve totally given control to your location permissions for _all web apps_ to yet another corporate driven point of failure.
don’t even get me started on the UI mess.
my tinfoil hat theory is that the browser is pushed by mostly bad actors trying to get data, while anyone providing a real user experience has a nice native app.
press F for my reputation.