@WarnerCrocker Not quite on board w/ "nothing has made a difference". Luckily, every abduction even potentially stopped by alarming someone, maybe with a whistle, 3D-printed or not, has made a difference to someone *Very* much. Life-alteringly much. Awareness and directly helping neighbors has made a difference. Protest and in-person support has made a direct difference on places ICE can and cannot act just as they please.
I'd concur that nothing *done without leaving home* substantially helps.
@WarnerCrocker I don't get it. Plastic, injection-molded whistles are cents apiece. You can buy packs of 50, and they get delivered quickly (not just from amazon, but also from sports and party stores). Letting your 3D printer "run 15 hours a day" is neither financially nor a time-efficient way to get whistles out to the public (even if they're very nice whistles).
Is this a way to feel like people are contributing something to a protest movement without having actually to go out into the cold?
@WarnerCrocker It sure feels like this is primarily to satisfy the "I've done something that only I can do" self-actualization needs of the owners of 3D printers, less than trying to help people in the most effective ways.
@tedyapo For other "classic" semiconductor vendors, I've been told these are probably "gapfiller" runs done when one of the older fabs/lines isn't busy producing high-margin long-term (milgrad?) parts, and the "run the dirt out parts" you get when reopening a line after maintenance, where you don't produce large-area die due to low yield, and for the small parts, the characterization costs are too high for it to make commercial sense to qualify them to the same degree as the higher-spec parts.
@janneke@barrelshifter not sure that's a fair distinction; on unhosted platforms ("bare-metal"), you still need (non-C) startup code to set up at least something like stack address(es), static storage before you can jump to a C function?
@gsuberland@xssfox well looking at 750 MHz center, I'd assume most of this is inductive pick up - after all, the six 1.5 V cells in the battery are wired up as a loop.
@LaF0rge I'm having a hard time putting a year to this: Obviously, pre-1993, due to the old post code, probably pre-1991 due to the "made in W-Germany", the English labelling says "(E)DSS1 era", i.e., post-1991?, the plastic colour makes it a "modern look" from the mid-1970s to the late 1980s, so a Siemens-modern look probably mid-1980s to late 2000s. 8P8C Bu4 puts it proooobably more on the modern side, and whatever Bu6 is.
@bert_hubert@vitaut uff, I was starting to look into why it takes ages for the component tables on an electronics components supplier site to sort a table with ~50 rows and ~20 columns, and my takeaway was not "someone's SQL library needs changes", but "whoever implemented the slowest sort algorithm known to mankind in a manner that needs DOM reparsing a couple ten thousand times instead of sorting the source data should probably have been their computer access revoked".
@steieio it does make a lot of sense from a Microsoft perspective, where software distribution still seems to be hard, indeed, and they for some reason don't like generic bulk device drivers. I've not had the worst experiences with dfu-util myself (thanks, openmoko/ @LaF0rge / @osmocom), and would honestly just have wished for more self- descriptor functionality bolted onto that protocol.
@steieio@osmocom@LaF0rge I mean, you should be able to do DFU via WebUSB even, so I really am having a hard time agreeing, especially since "copy a file to an emulated storage device, but relay on the OS don't doing out-of-order things or simultaneous file accesses, or checking what it wrote" is honestly just a terrible idea, as simple as it sounds to the user.
@alcinnz@simo5@david_chisnall on soft bits to do decisions based on analog signal observations, and the fact that aes blocks are relatively small and locally decryptable, would make me guess that channel decoders are the power-wise worse problem at the same rate.
@alcinnz@simo5 and @david_chisnall is also seeing the right problem there: the error correcting code decoders are usually pretty energy-hungry per payload bit, even as they are all specific silicon these days, because nobody can do 30 iterations of a giant graph message passing algorithm on frames far beyond 15000 bits in length in software. I don't know how these decoders compare to an AES accelerator in power per bit, but my guess is that the fact alone that they are working1/2
@alcinnz@simo5@david_chisnall you'd be right, and none of the high speed interfaces that even get remotely close to 1 Tb/s do it without extensive error correction. State of the art is that we correct errors, mostly using block codes with blocks as long as the requirements and medium permit.