Hacker News new | past | comments | ask | show | jobs | submit | _pmf_'s comments login

I'd also like to throw https://github.com/WerWolv/ImHex in the mix here.

Responsibility sink.

> tesla does not need to advertise

What do you think Elon's shenanigans are exactly?

> 2x memory looks like a naive implementation of just allocating an std::string from heap for each line. Due to heap fragmentation and various overhead it would quickly blow up.

Looks more line Qt's internal UTF-16 encoding in this case.

"Recycling" means "the landfill is on the other half of the globe".

if only, my sister was behind the recycling truck that just picked up at their house and saw it turn into the landfill.

> Barcode scanners are hilariously bad

Aren't they just USB HID (previously: serial) devices that literally just output key codes for the numbers detected?

Yes. And they can send all key scan codes, i.e Win+r cmd <enter> format c: <enter> or something...

The ones I have used worked like that. They gave wonky output if you scanned something that was not a bar code.

I also used a 2D scanner and it worked the same way.

If only!

Keyboard-wedge is only one of a dozen ways a barcode scanner can send data. Most also have legacy serial interfaces for use with old POS systems, so you have scantags that enable and disable those, and configure the baud rate, start bits, stop bits, parity bits, flow control (like a dozen different types), minimum idle time between subsequent codes, etc. And some of the old stuff isn't exactly ASCII, like there are systems that operate in MSI/Plessey mode which is all sorts of martian. It has its own whole config tree. I don't even remember how Nixdorf mode works, I never had to deal with it.

And even within USB, sometimes you emulate a HID keyboard and send scancodes, sometimes you enumerate as an actual USB HID barcode scanner (that's a dedicated device class), sometimes you emulate a USB CDC serial device and inherit all the serial config from above minus the baud rate. Oh, and sometimes you can configure the USB polling interval for performance.

Do you start with a special key/character to signal that a barcode is coming, or just begin vomiting digits into wherever the cursor happens to be? Pad shorter codes with leading zeroes? Do you send CR or LF at the end, perhaps both? Or some other key/character like tab?

Oh and keep in mind that some barcodes can do alpha characters too. Which keyboard layout are you emulating, because the whole world isn't US-English? Convert to upper or lower case? Filter characters? Send a different start-character to indicate that an alpha code is coming?

And then you've got the symbology selection. There are hundreds of different types of barcodes, and they're used for different things. Have you ever scanned a box and the scanner picked up a barcode from the shipping label rather than the UPC? That's because whoever set up the POS didn't disable the other symbologies. They should have. So there are config variables for all that. Even just the UPC/EAN/JAN family has a dozen subvariants, and some POS systems want a prefix to indicate which variant is coming down the wire.

Then there's scan tuning. How many times does the laser/imager need to read the code before it considers it good? Crank this up to increase confidence, crank it down to favor speed. How much "dead time" should the reader take after scanning one code before it can scan another code? How much should it have before it can scan the SAME code again? Picture the way a clerk whips products across the scan window and try to tune it so you can easily scan multiples of an identical product, without scanning the very same item twice if it remains within the window too long.

Newer scanners also have tunables for recognizing barcodes displayed on LCDs since customers now sometimes present coupons on their phone screens. That's its own whole can of worms and largely newer than my time in the industry so I don't know the specifics, but again it's a performance tradeoff depending on the situation.

There's also minimum and maximum distance and apparent line width, which can help in certain handheld situations (think of the handheld style used at convenience store counters) where it otherwise might pick up distant products on the counter by mistake. But sometimes you might want to be able to scan things from a few feet away, so that's configurable.

Then you've got UX variables. Beep after a good read? Configure pitch, duration, and volume. Different beep/tone for error? All of the above again. Turn the feedback LED(s) green/red for those statuses? Or does green mean "ready for scan", like at self-checkouts? Scanner always active, or only when activated by button push (handheld) or proximity sensor (pedestal) or scale (checklane)? Or active only when DTR line high (serial)? Timeout after activation if no valid read? There's so much more, this only scratches the surface.

Finally, all these config variables can be stored, recalled, defaulted, protected, and unprotected.

The fancier scanners have well over a thousand config variables you can set, for example: https://www.zebra.com/content/dam/zebra_new_ia/en-us/manuals...

In the Challenger case, the bad information has been deliberately hidden within the structure. They could just as well have pulled it up in the structure.

It's like saying variable font sizes are inherently bad because due to them, contracts can have small print sections.

A small set standardized data structures (vectors, maps) would do so much good for C.

That would be nice, then I wouldn't have to use non-standard stuff.

I made my own easy-to-incorporate-into-any-project library - https://github.com/lelanthran/libds - just copy the ds_*.h and ds_*.c into a project and you're good to go.

I'm not saying it will work for you, but it works for me.

So it's not standard nor cross platform, but I consider Glib to be the defacto standard data structures library. Have you tried it out?

For me, The Witcher 3 and Red Dead Redemption had the most compelling environments. I spent probably half of my play time just walking-riding around.

> it's a book filled with solutions to imaginary problems.

Have you even read it? I'd say it has more deep real world examples than almost any other SW engineering book I've read.

IME it happens often that these categories overlap, when software gets entangled in incidental compexity.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact