Define a random 128 bit key that you will never change. Use that key to encrypt 128 bit integers in sequence using AES-128, each one comes out as a, for all practical purposes, unique unpredictable ID.
The best answer so far. It describes exactly what was going on. LLM users should read it twice, especially if "confession" didn't make your brain hurt a bit.
Yeah the tutorial I linked was from Mango Jelly for FreeCAD 1.1 :) He seems to have a perfect balance of getting it done, and you understanding what you are doing.
Yeah I still consider Solid Edge very good. Easy to work with, does not require internet, no stupid limitations (like the 10 model limitation for Fusion). Many tutorials, etc. But still, they might revoke their free license at any moment and I am out of a tool, and wasted experience.
Yeah I actually have. I really liked the concept, but I designed a cylinder with many holes (think a robust sieve) and it just crashed when the number of holes grew too great. Even the OpenCL/MP version. I felt it being unstable in other ways too so I did not make it my go to tool. Sadly it also seems it's not being developed much.
EDIT: Missing fillets and chamfers we're also a big problem for me - probably I'm just a newbie maker and want unreasonable things, but still.
I'm a occasional hobbyist maker and i've used Autodesk Fusion, Solid Edge, OpenSCAD and other niche parametric programs, but always felt FreeCAD was too complex. But I really wanted it to work for me because it's FOSS and 100% offline. So with the new FreeCAD 1.1 RC I found an hour long tutorial and dove in.
(1.1 is supposedly much easier to work with)
After doing the tut I can say that 1.1 is very nice, i can uninstall Fusion and Solid Edge finally :)
Because stocks have a tendency to go up even when they should be going down. And when you decide that it probably isn't going down, it will go down. Timing the market isn't a reliable way of wealth generation. Long term investing is.
Currently it seems that Google is pushing for hardware attestation, so you might be able to install Graphene/Lineage if your phone manufacturer allows you to unlock your bootloader, but many Play Store apps won't work as they'll detect your root. It's actually gotten pretty insane how every low-value app considers themselves the centre of the world and unable to run on a rooted device.
Example: the loyalty card app for a local store chain - there's no money in it, I can just get some discounts when I use it. So an attacker would have to steal my phone, somehow unlock it, and then they can use my loyalty card (btw which is free to obtain for anyone and there are no tiers) to get some discounts. And for that, they have implemented a pretty decent root checker which i had to put in some effort to overcome. And there are many more like it.
That's also a large part of the issue IMO. I currently _have_ root on my rooted and Lineaged Poco F3. But as hardware attestation is becoming the norm I am deeply worried about the future. I have been a pretty eager Android fan due to its achievable-if-savvy openness. If I lose root and sideloading, then Android is dead to me. There would be nothing valuable in it, just another corporate walled garden.
People are free to rip their purchased media. He even says that he buys blurays/dvds in the article.
One can assume anything, but a completely legal setup can look exactly like that. Especially as most of those are relatively old movies - looking like a list of purchased blurays/dvds to me.
I hope I didn't come off as angry or anything, I was just very surprised by the behaviour :)
I am talking from some experience as I had to convert circa 40k lines of untyped code (dicts passed around etc) to fully typed. IIRC this behaviour would have masked a lot of bugs in my situation. (I relied on mypy at first, but migrated to pyright about 1/4 in).
But otherwise it's good to hear that this is still in progress and I wish the project the best of luck.
Because to me this seems like a fantastic example of a highly possible mistake that a typechecker _should_ catch. Without defined types in this situation a couple of things could happen: 1) it gets printed or passed to some other Any method and the typechecker never yells at you and it crashes in production 2) the typechecker catches the error somewhere long down the line and you have to backtrack to find where you might be appending a str to a list[int].
Instead it could mark it as an error (as all the other checkers do), and if that's what the user really intended they can declare the type as list[str | int] and everything down the line is checked correctly.
So in short, this seems like a great place to start pushing the user towards actually (gradually) typing their code, not just pushing likely bugs under the rug.
> pyrefly, mypy, and pyright all assume that my_list.append("foo") is a typing error, even though it is technically allowed (Python collections can have multiple types of objects!)
> If this is the intended behavior, ty is the only checker that implicitly allows this without requiring additional explicit typing on my_list.
EDIT: I didn't intend my comment to be this sharp, I am actually rooting for ty to succeed :)
ORIGINAL: I am strongly against ty behaviour here. In production code you almost always have single type lists and it is critical that the typechecker assumes this, especially if the list already has same-type _literal_ items.
The fact that Python allows this has no bearing at all. To me having list[int | str] implicitly allowed by the typechecker seems like optimizing for beginner-level code.
The graph seems a bit too much. It says that GPS 110 means ~125 on the odo. Although from personal experience I'd say it's more around a delta of 5 at those speeds, and 3 for lower speeds.
Border Force looked into a later order of thorium, and that caused them to go over all his past imports which contained the plutonium. The plutonium had been sitting on the guys shelf for months at that point.