While driving through upstate New York on a camping trip I found a maple syrup shop run on the honor system. Leave the money in an unlocked box. It was shocking. I bought a gallon.
I had the same experience in upstate NY. So many little boutique country stores with craft and art tables outside that just had venmo signs next to the crafts. My wife bought a few items and we were pleasantly surprised to see how many public purchases were made to that venmo account. And it wasn't super cheap junk/stuff either.
We have quite a few road side stalls like this around where I live in NZ, Honey, eggs, swedes are a common one. You hear of the odd theft from them every now and then but for the most part it seems to work well.
If you've been to the rural USA you'd know it's just high-trust (and the middle of nowhere). They're pretty common for low-value things like corn and farm produce; but I've seen syrup and honey, too.
There might be a camera but since there's usually no power, it'd have to be some sort of trail/game/deer cam. What would you do with the result besides some vigilante frontier justice? No cop anywhere but daytime children's TV is going to investigate the Case of the Stolen Syrup.
We once went to Florida and saw some open orange farms. We wanted to buy some, but there was nobody in sight - we got very confused until we saw a box which said "$X a bag"; there was a sack of bags nearby. My mind was blown.
I’ve been agonizing over getting the Framework Desktop for weeks as a dev machine/local LLM box/home server. It checks a lot of boxes but the only reason to look at the Framework Desktop over something like a Minisforum MS-A2 is for the LLM and that seems super janky right now. So I guess I’ll wait a beat and see where we are later in the year.
My main worry about all the Minisforum, Beelink, etc. PCs is: potential lack of UEFI firmware updates (does anyone have experience with how good they are with updates?) and potential backdoors in the UEFI firmware (either intentionally or unintentionally). A China-aligned/sponsored group has made an UEFI rootkit targetting ASUS/Gigabyte mainboards: https://www.spiceworks.com/it-security/vulnerability-managem... Why not require/compel certain companies to implement them directly?
I bought 3 Minisforum machines for a Kubernetes cluster and they didn't make it 11 months. They weren't even powered on most of that time. They just completely freeze with a black screen, and randomly enough to where every time I think maybe I figured out a fix it just crashes again a day later.
My Minisforum M780 XTX has been rock solid for 20 months now. Bought it as a remote development box since I needed more RAM than my MacBook Air and didn't feel like shelling out $3K for a 64GB MacBook Pro. Generally prefer the remote development experience since it means the laptop stays cool, just a pain not being able to work at a cafe now and then.
Even if there aren't backdoors, things like this[1] affecting AMD Zen CPUs, where microcode signing keys changed and thus the firmware needs to be updated to allow the new keys, would prevent machines from using new microcode updates.
probably doesn’t make sense as a home server unless you need the massive compute. i have a couple lenovo mini pcs (m75q, various generations, AMD) that I paid a total of $500 for on ebay. they’re so easy to find and handle most tasks swimmingly.
Surely if running a local LLM is a goal, you're going to be disappointed by any small form factor desktop. Even an M4 Max is slow compared to a 5 year old rtx 3090, and the M4's only advantage is that it can run larger models, but very slowly [1].
I'm not sure, but you could always just buy the Minisforum BD790i X3D [1]. Then, you'd be able to choose your own fan and case, and you can make it arbitrarily quiet by selecting a good fan. Early BD790i boards had a bug where losing power causes it to reset all BIOS settings, but they fixed that in later batches. I wonder when they will come out with a 9955HX version. Another good thing about this board is that it has two PCIe 5 NVME SSD slots with active cooling, which is a lot better than most other mini ITX boards out there, including the Framework.
I did exactly this, put it in a 2U case. Fantastic performance, but even with the best Noctua I could put on it the CPU fan sounds like a Hawker Harrier doing VTOL when it's under load. Don't regret the board, but wish my rack was in another room now.
You can adjust some fan settings in the BIOS, like what temperature it starts turning on, the PWM setting when it first turns on, and the temperature at which it hits PWM of 100%. After tuning those a bit, mine is pretty quiet unless I'm compiling with all cores or something.
I wonder if you plotted layoffs cycles you’d see a big gaps for tech companies for the last couple years since RTO orders will have the same effect.
Reading about the different RTO rebellions is interesting. I know multiple people who have ended up in a half day schedule that they really like. All meetings scheduled before noon-ish, then head home to focus on work. These are all kind of against company policy but there’s a shield of willingly ignorant managers between the executives and workers. As long as the managers can say “as far as any metrics I have access to tell me my people are in the office the required days per week” they’re ok with it.
I saw someone describe python as “stressful” for this reason and I couldn’t agree more. It’s difficult to have confidence in any change I make or review. I need to sit down and manually exercise codepaths because I don’t get the guarantees I crave from the language or tooling. While with the small amount of Rust code I’ve written lately I could yolo changes into production with no stress.
Agreed. I had to work in a larger Python codebase after spending a few years with Go and Rust and the drop in logical confidence around the language was remarkable.
I have, roughly, sworn off dynamic languages at this point. Although I have dreams of implementing a firm typed system over Common Lisp.
Same, though my trauma was Ruby. Those Rubyists who were apparently born with the language spec in their heads can do amazing things, but I am a mere mortal who needs to be told I wrote bad code right when I wrote it, not told at 2am on a production server.
In a large enough code base, there is no "your code". There is the code you wrote today, there is the code you wrote two years ago, there's all the code people are writing around you.
I change a function's arguments, I'm _pretty_ sure I caught every place it's called (spoiler alert: I didn't, because someone calls functions dynamically based on their names with call_user_func_array, maybe), and I ran the test suite - everything works, and I've fixed what doesn't.
Except some of that old code written 8 years ago didn't have good tests, or didn't have any tests at all, or didn't cover the specific code path.
And now it's 2am on the production server.
Now, you could tell me - Pavel, you're an engineer, you should be sufficiently dedicated to your craft to verify that the tests are testing those paths, you should find all those instances where that function is called (a few dozen times across the codebase), and check that those tests exist and are good. And you're not wrong! I should be doing cleanup in the codebase as I go, washing those dishes while I wait for pasta to boil or whatever...
... but now I've given myself two more actual engineer-weeks of work for a change that just needed to add a flag to a function to make sure only premium users get emails when something happens. My manager will be thrilled to hear it. Do you think I'll get a raise?
I’m assuming that Python code base didn’t have thorough type hints. What if it had? Would Go still feel safer? I know these aren’t checked in runtime, but Python type system seems more thorough than Go’s, so shouldn’t a Python code base fully typed be even safer than Go? If so, why not?
(I know Python type checks aren’t mandatory, but for this question assume that the type checker is running in CI)
You're hand-waving the insane amount of effort that would be required to type every bit of Python code that gets executed. You get that by default in statically typed languages.
Even then, you're reliant on the correctness of a 3rd party tool vs a 1st party compiler. It's never going to be as good of an experience.
Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s.
One difference is that Python's type system is unsound. You can write code that passes `mypy --strict` but still contains functions that, for example, claim to return an `int` but actually return a `list` [0]. AFAIK it's not possible to circumvent Go's type system in such a way.
The biggest limitation of Go's static type system vs. Python's type hints system that I can think of would be the lack of union types, with nullability a close second (and it's just a specialized application of union types in Python). An interface in Go can be anything under the hood, though you at least know that, whatever its concrete type, it does implement the methods exactly as defined.
You can definitely circumvent Go's type system with unsafe operations (with FFI also recognized as inherently unsafe) but that's a clear boundary that you know you're crossing (albeit not quite as clear as e.g. in Rust).
Since Python type checking is functionally optional, it implies that somewhere, somehow, someone has opted out, or has used a type checker that differs subtly but unpleasantly from the one you're using. Python's type checker systems are fundamentally a _linter_ more than something like Java or C...or Rust.
It's not about feeling. It's about the theorems you can make about the codebase. With Python the answer actually is ¯\_(ツ)_/¯.
Yeah, that's a common argument for dynamic typing. You're writing tests anyway (right?), and those will catch type errors and many other kinds of error. Why bother with a separate level of checking just for type errors?
I personally believe it's a valid argument (others will disagree). IMO the main benefit of static types isn't for correctness (nor performance) - it's to force programmers to write a minimal level of documentation, and to support IDE features such as autocomplete and red underlines. Hence the popularity of Python type hints and TypeScript, which provide these features but don't fully prove correctness nor provide any performance benefit.
Except now you're writing and maintaining twice the amount of code instead of relying on the compiler and/or type checker to help you catch those errors
Sorry, but I don't agree that static typing is a replacement for unit tests. I can see static languages having fewer unit tests, but it's not going to eliminate them.
Static typing is a replacement for unit tests aimed to catch type bugs. Also, no one has 100% code coverage so might as we get some guarantees for granted.
I understand that statically typed code doesn't mean bug-less code, but I always find it odd that dynamic language enthusiasts feel like they need to stretch the benefits. Dynamic languages are great for many things. Strictness is not one of them and that's fine.
Sure, but only some of the unit tests are about values. Others, at least in my experience, are any handing various aspects of the implied types of values, and those can largely be removed.
Moreover, a good type system can also force the values to be right by enforcing certain invariants directly in the type system. For example, let's say I have a function `deleteProjectAs(user, project)` that deletes a project, but it only works if the user is an admin, otherwise it throws an error. I can write a bunch of tests that validate that this function checks that the user is an admin in all sorts of different cases, but with a type system I can write something like `deleteProjectAsUser(user: Admin, project: Project)`, and this guarantees at the type level that no non-Admin user can delete a project.
The point here is not that types can replace all tests, but that well-designed types can get rid of a lot of them.
You're tearing down a straw man. Your parent poster did not say it eliminates tests. He said static typing mean less tests. He didn't say static typing is a replacement for tests either.
One of the big advantages of Rust's type system is that, if you decide you want to change something (add a parameter, give a type a lifetime, rewrite an entire module), you can just do that, and then follow the errors until they're all gone. Often, once the types have been fixed again, the result will work first time when you try and run it.
In this regard, Rust (and other languages where lots of data invariants can be encoded in the type system) is very flexible and easy to maintain indeed, because you can easily make changes, even in very old or poorly-maintained code, without having to worry about the consequences. Moreover, rather than writing all the unit tests yourself, it's as if the compiler is writing the unit tests for you.
In fairness, you can't encode everything in the type system, so you still need unit tests in top of that, but in my experience you can get away with far fewer. In general, I would say that Rust's type system, when combined with unit tests, is far more flexible, powerful, and easy to maintain than dynamic Python with only unit tests.
Your 2-3 points remind me of the quote by Ludwig Wittgenstein: “The limits of my language means the limits of my world.”
Of course if you limit yourself only to problems that can be effectively solved by type system, then it may work. It is like limiting yourself only to those text processing tasks where regexs work. Yes, some text processing tasks may be much more effectively solved using a regex. But it is obvious that at some point in a more general case grep can’t replace python. It may be less apparent for compiler vs. python case but the general logic is the same.
Nobody is "limiting" themselves to anything. That's not a counterargument you're making.
We all deploy to production, dude.
Strong static typing (Rust), even only dynamic strong typing + pattern matching (Elixir), are leagues better than Python. Literal 3x - 7x less code and less production errors both in Elixir and Rust, over the course of 5 years.
You're the one limiting yourself. Expand your horizons.
If using python with type annotations, linters like ruff and mypy do a great job at identifying issues. It's no substitute for tests and nor will it give you the same guarantees that rust will at compile time. But I think it improves the base quality of the code.
Yeah I see what you mean, you can always disable specific features, but I think that's a habit mypy tries to enforce. They consider redefining a variable bad practice.
Even in rust you have to be explicit about doing the same thing with an extra "let" statement.
Yeah that's fair enough, and I've lived with it because of how good MyPy is. But I always end with weird variable names like uuids_as_list as a result!
We had serious reliability issues with USB versions that were only solved by switching to the D457 model with GSML connectors. Those needed other hardware vendors to build in support for it to work but once that was all done we never had an issue again. Happy times going from alerts daily of the camera dropping out to alerts never.
We managed to get pretty solid reliability with the USB C versions, to the point where I can't remember the last time we had a flaky robot due to this. I can't remember specifics of what we fixed (I think it was a combination of screw-in connectors at he camera, good cables, and kernel stuff). But yes... pain until then.
I was working in a college job for a pharmaceutical distributor when the New England Compounding Center outbreak happened. I think that dropped a nuke on the whole industry. We stopped dealing with compounding pharmacies after that because that whole thing was more like a matter of when not if.
I'm most familiar with them for off label ocular injections. Avastin is a common medication for colorectal cancer, but has an extremely similar biologic to Lucentis, used of ocular injections. Compounding pharmacies will breakdown Avastin because it is cheaper than Lucentis, and pre-fill disposable syringes.
I have seen it with my own parents and my wife's parents first hand. Frankly, I think the lack of social interaction is a big part of it.
When they're working, they're regularly talking to people outside their comfort zone about potentially challenging questions. That gets largely shutdown once you retire.
Both my parents were in a huge rush to retire early, and now they just sit at home and scroll Facebook. I don't see the appeal.
I didn’t appreciate this until covid and wfh. I’m an introvert and am in my happy place sitting in front of a computer or with a book. But I was losing my mind and had to be actively social for the first time in my life. I can see a decade of living like it’s Covid turning my relatively healthy, relatively young brain into soup.
Leaning into stereotypes, the older women in my family did just fine in retirement because they just started doing social activities full time. If anything they retired and got busier. The older men sometimes did ok but usually did worse.
That is why volunteering when you are in retirement is a win-win. Very few others have the time for what is an absolutely necessary part of society, and it is great to keep your mind and heart active while you recall your life and use its lessons to give back to others. Any sort of volunteering will lend itself to that. For example, Jimmy Carter built houses, and it seems to have done him wonders.
Social interaction must be important, but also the fact that work doesn't ask you how tired you are, you have set of tasks and go. When being master of my own time, I can imagine I would veer towards more fun activities which may not have that forceful aspect and would be done mostly alone.
And super true for those parents, my goal is to travel massively as much as my budget and health will allow it. Backpacking all around south east asia, thats what keeps me pushing to work on earlier retirement. Sitting at home unless forced, no thank you thats a downward spiral
>>Both my parents were in a huge rush to retire early, and now they just sit at home and scroll Facebook. I don't see the appeal.
My retirement plans look somewhat similar to how Knuth spends his time. Long hours of deep intellectually challenging work. Driving long distances and eating tasty food some where far away.
Most of retirement motivation comes from feeling the sun during weekdays. There is little point to be sitting whole day at home.
And from what I've heard on the grapevine, life expectancy drops among those who retire relative to those that don't. This makes sense: many people don't seem to know what to do with themselves if they're not "officially employed", so when they retire, they become aimless, and they sort of decay and disengage from living.
Though is that causation or correlation? I can imagine that people with all kinds of illnesses would also retire sooner than people who are still in peak health.
Everything I've read about pledge and unveil really admire the approach and the results but it didn't seem to have a big impact outside of OpenBSD. It took ~20 years for OpenBSD's CSPRNG to be re-implemented everywhere else maybe we're operating on a similar timeline here.
I’m more bearish about LLMs but even in the extreme optimist case this is why I’m not that concerned. Every project I’m on is triaged as the one that needs the most help right now. A world when dozen projects don’t need to be left on the cutting room floor so one can live is a very exciting place.
They use other models to judge correct-ness and when possible just ask the model output something that can be directly verified. Like math equations that can be checked 1:1 against the correct answer.
