Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)LI
Posts
1
Comments
381
Joined
2 yr. ago

  • This is a good point. Franchises are less likely to have a recognizable corporate name, if they even own the property at all. But for more established companies or long-time small businesses, the owner entity's name might be a good giveaway as to what they did.

  • Recent history would be reflected in Google Street View, but that only goes back to maybe 2011 and only for some parts of the USA.

    Going further back, you can try property ownership records, or even just searching for the address online, setting the time window to before the current business came to be.

  • I would guess that High Street in the (mostly British?) commercial shopping area sense would have evolved from "highway", meaning a principal or main road, which in turn evolved from "high way", being those roads constructed above grade, so that water would drain off the road into the adjacent ditches. The Romans [citation needed] tended to build all-weather roads like this.

    In American English, "highway" would be an odd term to apply to a shopping district -- usually referring to a higher-speed road -- but in some contexts, highway is understood to be any improved road. The California Vehicle Code uses this definition, so that "highway" basically means any public road.

    At least in California, roads named High Street do exist, but don't necessarily corespondent to being physically tall over its surroundings or other steets. If anything, a typical High Street is often the same in character as another town's Main Street, which sort-of returns to the British meaning of shopping area again, at least in small towns.

  • I think you asked about how to improve a few days ago, so I'll answer now about how to start learning programming. In a lot of ways, programming is describing what you want the computer to do, but in a language it understands. So half the effort is building an intuition of how to break down a task into individual parts which the computer can work on, and the other half is to actually write the instructions for the computer.

    The first part is common to all the engineering fields, but shows up elsewhere like in art (eg deconstructing a human face into drawable geometric shapes), daily life (eg navigating a car or public transit by making various left and right turns in a certain order) and other fields; familiarity with any of these will put you a step forward. Basic programming tutorials are useful in developing an awareness of what a computer can easily work on, and by exception, what it cannot.

    The second part requires learning the programming language and its grammar, which I think the general curriculum for programming courses or online tutorials mostly has covered. If you're already familiar with an existing programming language, then a new language can be framed as a translation from the first, mostly. Some features don't translate at all -- eg explaining Rust memory ownership to a C programmer -- so those will have to be rote learned.

  • My town has previously distributed tape dispensers specifically to tape up battery ends, for exactly the scenario of tossing them loosely into bags. It's a good idea, although they seemed to have stopped distributing for some reason. It was simple cellophane tape, like for mending paper, but wider than normal.

  • In the US, Home Depot and Lowes have drop-off bins for rechargeable batteries by the front door.

    Try to tape up at least one end of the battery or one lead from the battery, to prevent discharge fires.

  • The first link is an SFF-8087 to 4x SFF-8482. While this cable could technically support SAS3 speeds, the SFF-8087 connector was specified for SAS2, not SAS3. As a result, you won't really find any HBAs that have an SFF-8087 connector and do SAS3 over it. This cable is incompatible with the 9300-8i from your second link. I would choose something more like this: https://www.amazon.com/dp/B01GPD5KFK . Also be advised that if your SSD isn't recognized with this cable, the reviews mention that the 3.3v power pin -- if you have one at all -- might need to be disabled, to avoid PWDIS issues.

    For the second link, that Inspur 9300-8i appears identical to the HBA I have, and it's worked fine for me, although I only have SAS2 drives hooked up to it right now. The nice thing is that the listing advertises "IT mode", which was important to me, because burning firmware to switch to IT mode is a sad experience.

    EDIT: BTW, when you receive this drive, you should probably dump the SMART data to see how much lifetime is left on this SSD. This is an enterprise SSD, so it's possible that it came from several years of use as a caching drive in a server somewhere. That could do a number to its remaining lifetime, but I would imagine its performance would fit well for your use-case.

  • BTW OP: when you get this set up, please run some benchmarks and tell this community how it performs. I've had a free PM1633A sitting on my desk for 1.5 years, just because I haven't gotten around to it. I'm keen to know how it behaves.

  • An aside: one-to-many breakout cables have a forward and backward variety, and care must be taken to avoid buying the wrong one. This link explains the difference, which is still applicable to SAS3: https://forums.unraid.net/topic/6723-sas-to-sata-cables-forward-or-reverse-which-where-why/

    Note that some combinations of backwards breakout cables simply don't exist, so there might be only one version available for sale. Still, read the product descriptions carefully for which end is meant for the HBA and which end goes to drives or the backplane.

  • To summarize a few details, the PM1633A is a SAS3 (aka SAS 12 Gbps) SSD drive, which accepts an SFF-8482 plug. This SFF-8482 plug is the one named in the SAS3 standard for use on drives. You mention the LSI 9311 HBA, which does support SAS3 and has a pair of SFF-8643 receptacles, which is specified in the SAS3 standard for use on backplane aggregators. That is to say, when multiple drives are bundled up onto a single cable.

    When used for SAS3, SFF-8643 supports up to four drives. And so you will find forward-breakout cables online that go from SFF-8643 to 4x SFF-8482.

    The cable you mentioned -- an SFF-8643 to SFF-8639 -- is meant for U.2 drives. Because of the 4x PCIe lanes used for U.2, a single drive uses all the pins in an SFF-8643 plug, which is why this cable can only attach to a single drive. Because SFF-8639 is backwards compatible with SFF-8482, this could still be used for SAS3 drives, but it would waste the other three "lanes" in the cable.

    With all that said, I would not recommend the cable you listed, and instead replace it with the aforementioned forward-breakout to 4x SFF-8482. This way, you can later buy three more SAS3 drives. I presume you're not planning to ever use U.2 here.

    Also, regarding the choice of HBA, was there a reason you chose the 9311? I have both the venerable 9300-8i and a newer 9305-16i. Both work great for me and support SAS3. It's notable that power and heat is lower on the 9305. The 9300, 9305, and 9311 all have the same pair of SFF-8643 connectors.

  • I find that reading a lot of code helps. From the bad code, take note of what to avoid. From the good code, take note of what to emulate.

    To be clear, it's often more useful to read code within your specialization than to read any ol piece of code on the Internet. That said, drawing from other programming languages and across a rich variety can be useful into itself.

  • Borrowing some of the points from that video, a high-end bicycle -- let's say a road bike -- is very close to what could actually be used in competitive road cycling, with all the technological and material sciences advances included. Whereas a standard car like a Toyota Corolla would need substantial further investment to bring it to competition grade (eg rallying). And a high-end, track-inspired road-legal car would be exceeding $100,000 easily.

    Certainly, in the average quality range, the price of your average road bike and your average automobile will be a chasm away. But I figured your question is focusing on the high end of bicycles.

  • This was an interesting read, so thanks for writing!

    My background: I am an embedded software engineer by trade, and a tinkerer as one of my hobbies. I've played around with microcontrollers (MSP430, AtMega328p on the Arduino) and microprocessors (STM32, ARM64 on RPi) and have done a small amount of board design with KiCAD.

    After reading your post, I thought about what platform is my "go to" for particular applications, and why. And what I arrived at is that it's not as important what each platform offers, but how it fits into what I want to build. That is, how integrable it is.

    When I have a hobby project that just needs a SPI bus and a programmed sequence, I might reach for an MSP430 in DIP form-factor, or the Arduino with the intent to program the 328p and then extricate it to use alone for my project. The DIP format is what makes me lump these two chips together, as both are reasonably comparable but have their own unique features, like low power consumption or 5v input.

    Similarly, if my project needs networking, I would definitely lean into microprocessors, but now I have to settle on the format before proceeding. Specifically, if I want to use the RPi, then perhaps my design will take the shape of a Hat. If instead I want to build around an STM32 chip, then I need to provision its support hardware. The latter is fine, but I don't exactly trust my EE skills to do this every time lol

    As a result, what I would like -- as an embedded engineer -- is a common microprocessor platform which can be swapped out, with a common pinout and connector. I know in the industrial space, they have standards like COM Express to do exactly this, but I'm not sure if that's exactly the right direction to go, since those tend to be x86 based. Maybe something like the RPi Compute Module, but FOSS.

    To go with it, I'd also want a common module format, same as how RPi has Hats and Arduino has Shields. Again, industry has the OCP Standard, which conveniently breaks out a PCIe interface, but there isn't a lot of PCIe used in hobbyist work. But maybe it's time to change that? IDK

    Thanks again for writing this; it's given me a chance to think about what I'd really like to have in the proverbial toolbox.

  • As a fairly-new ham radio operator, I need to improve my numbers pronunciation so maybe I'll start reading the time like that and see how other people react.

    Already, I get a number of confused-then-resigned looks when saying "sixteen o'clock" haha

  • Here in California, I've heard both "military time" and "24 hour time" used interchangeably for writing the time as "03:45" or "16:20". That said, I've heard -- citation needed -- that proper military time does not use the colon, such as "1600", pronounced as "sixteen hundred hours".

    As for why the public might refer to this generally as "military time", it may just be that that's the most common, well-known use-case in the States, outside of the sciences. I personally use 24 hour time on all my devices, but I've come across many people who prefer clockfaces or AM/PM, probably out of habit.