• 2 Posts
  • 48 Comments
Joined 10 months ago
cake
Cake day: September 11th, 2023

help-circle



  • I’ve recently been thinking a lot about the recyclability of plastic. I have several stacks of plastic drink cups from various fast food joints in my kitchen; as much as possible, I try to save up and bundle together similar types of plastic before I throw it in the recycling bin, to try to save some sorting effort. And in doing so, I noticed something.

    The thing is, a lot of single-use plastics have very similar properties. PETE, HDPE, Polypropylene, solid polystyrene, they’re all used to package similar or identical products. I think they’re more or less interchangeable, and the choice of a given plastic for a given application has more to do with cost, availability and the preferences of the product engineer than any specific material properties of the plastic itself. There’s obviously going to be some exceptions, but I think those are going to be few and far between, and a lot of them could be addressed by switching to other materials.

    I think a great first step would be for regulators to encourage/force industries to standardize on one or two types of plastic at most, and eliminate plastics that aren’t worth recycling, like polystyrene. That should reduce the manual labor required by a significant amount once the other plastics are eliminated from the waste stream, and make it feasible to recycle plastics locally instead of shipping them off to a third world country.

    I think companies should be taxed or otherwise penalized for the plastic waste they foist on consumers, because often there’s little choice involved unless you want to boycott a company entirely. If I wanted to eliminate plastic cups from my life, I’d pretty much have to stop getting fast food altogether (yes I know I should probably do that anyway, but that’s beside the point). A tax on bulk purchases of plastic may end up being passed down to consumers, but the revenue could be put towards subsidizing production of more renewable materials.

    I think food stamp programs could be a strong driver for change on this, as they could refuse to cover products that generate excessive waste. With enough warning, there should be enough time for companies to switch their products to be compliant with little disruption to the consumer.


  • Wanting to and actually doing it are two different things.

    The problem is that open source devs also have to be their own project managers, but those two jobs have very different skillsets.

    In regular software development, it’s the PM’s job to deal with the drama, filter the idiocy out and collect concise and actionable user stories, and let the developers just write code.

    In open source, you tend to deal with a lot of entitlement. All kinds of people, who never gave you a dime, come out out of the woodwork to yell at you over every little change. The bigger and farther reaching a project is, the more this happens, and it wears you down. I can only imagine what it’s like working on a huge project like GNOME.

    And the toxicity feeds into itself. Be kurt with one person, and suddenly it gets out that you’re an asshole to users. Then people come in expecting hostility and react defensively to every little comment. And that puts you in the same mindset.

    At the end of the day, you can’t satisfy everyone. Sometimes you gotta figure out how to tell someone their feature request is stupid and you’re not gonna work on it, especially not for free. And a lot of people need to learn to try to fix problems themselves before opening an issue. That’s kind of the whole point of open source.



  • At this point, no. But it’s still incredibly annoying and a little spooky when I’m laying in bed and I see my computer screen light up in the next room when it’s not supposed to.

    It’ll even wake itself from sleep when it wants to update, but it won’t start it automatically, I think because it hits the lock screen.

    I’ll probably try Linux on ir when Windows 10 hits EOL.







  • I ran up like a $5k bill over a couple weeks by having an application log in a hot loop when it got disconnected from another service in the same cluster. When I wrote that code, I expected the warnings to eventually get hooked up to page us to let us know that something was broken.

    Turns out, disconnections happen regularly because ingress connections have like a 30 minute timeout by default. So it would time out, emit like 5 GB of logs before Kubernetes noticed the container was unhealthy and restarted it, rinse and repeat.

    I know $5k is chump change at enterprise scale, but this was at a small scale startup during the initial development phase, so it was definitely noticed. Fortunately, the only thing that happened to me was some good-natured ribbing.



  • This only happens when both network connection on the host are active.

    I’m not a networking expert by any means but this seems like a pretty strong hint that it’s a routing issue.

    Check the routing tables on the host? I’d bet that the internet is only reachable on the LAN interface (again, not an expert but one of them has to take priority, right?). I’m guessing that disconnecting the LAN interface changes the routing to go through the WLAN interface instead.

    You could possibly add a static route to work around this: https://libvirt.org/formatnetwork.html#static-routes




  • Actually, Android doesn’t really use Dalvik anymore. They still use the bytecode format, but built a new runtime. The architecture of that runtime is detailed on the page I linked. IIRC, Dalvik didn’t cache JIT compilation results and had to redo it every time the application was run.

    FWIW, I’ve heard libgcc-jit doesn’t generate particularly high quality code. If the AOT compiled code was compiled with aggressive optimizations and a specific CPU in mind, of course it’ll be faster. JIT compiled code can meet or exceed native performance, but it depends on a lot of variables.

    As for mawk vs JAWK vs go-awk, a JIT is not going to fix bad code. If it were a true apples to apples comparison, I’d expect a difference of maybe 30-50%, not ~2 orders of magnitude. A performance gap that wide suggests fundamental differences between the different implementations, maybe bad cache locality or inefficient use of syscalls in the latter two.

    On top of that, you’re not really comparing the languages or runtimes so much as their regular expression engines. Java’s isn’t particularly fast, and neither is Go’s. Compare that to Javascript and Perl, both languages with heavyweight runtimes, but which perform extraordinarily well on this benchmark thanks to their heavily optimized regex engines.

    It looks like mawk uses its own bespoke regex engine, which is honestly quite impressive in that it performs that well. However, it only supports POSIX regular expressions, and doesn’t even implement braces, at least in the latest release listed on the site: https://github.com/ThomasDickey/mawk-20140914

    (The author creates a new Github repo to mirror each release, which shows just how much they refuse to learn to use Git. That’s a respectable level of contempt right there.)

    Meanwhile, Java’s regex engine is a lot more complex with more features, such as lookahead/behind and backreferences, but that complexity comes at a cost. Similarly, if go-awk is using Go’s regexp package, it’s using a much more complex regex engine than is strictly necessary. And Golang admits in their own FAQ that it’s not nearly as optimized as other engines like PCRE.

    Thus, it’s really not an apples to apples comparison. I suspect that’s where most of the performance difference arises.

    Go has reference counting and heap etc, basically a ‘compiled VM’.

    This statement is completely wrong. Like, to a baffling degree. It kinda makes me wonder if you’re trolling.

    Go doesn’t use any kind of VM, and has never used reference counting for memory management as far as I can tell. It compiles directly to native machine code which is executed directly by the processor, but the binary comes with a runtime baked in. This runtime includes a tracing garbage collector and manages the execution of goroutines and related things like non-blocking sockets.

    Additionally, heap management is a core function of any program compiled for a modern operating system. Programs written in C and C++ use heap allocations constantly unless they’re specifically written to avoid them. And depending on what you’re doing and what you need, a C or C++ program could end up with a more heavyweight collective of runtime dependencies than the JVM itself.

    At the end of the day, trying to write the fastest code possible isn’t usually the most productive approach. When you have a job to do, you’re going to welcome any tool that makes that job easier.



  • Android has actually employed a hybrid JIT/AOT compilation model for a long time.

    The application bytecode is only interpreted on first run and afterwards if there’s no cached JIT compilation for it. The runtime AOT compiles well-known methods and then profiles the application to identify targets for asynchronous JIT compilation when the device is idle and charging (so no excess battery drain): https://source.android.com/docs/core/runtime/configure#how_art_works

    Compiling on the device allows the use of profile-guided optimizations (PGO), as well as the use of any non-baseline CPU features the device has, like instruction set extensions or later revisions (e.g. ARMv8.5-A vs ARMv8).

    If apps had to be distributed entirely as compiled object code, you’d either have to pre-compile artifacts for every different architecture and revision you plan to support, or choose a baseline to compile against and then use feature detection at runtime, which adds branches to potentially hot code paths.

    It would also require the developer to manually gather profiling data if they wanted to utilize PGO, which may limit them to just the devices they have on-hand, or paying through the nose for a cloud testing service like that offered by Firebase.

    This is not to mention the massive improvement to the developer experience from not having to wait several minutes for your app to compile to test out each change. Call it laziness all you want, but it’s risky to launch a platform when no one wants to develop apps for it.

    Any experienced Android dev will tell you it does kinda suck anyways, but it’d suck way worse if it was all C++ instead. I’d take Android development over iOS development any day of the week though. XCode is one of the worst software products ever conceived, and you’re forced to use it to build anything for iOS.