ch00f

joined 1 year ago
[–] ch00f@lemmy.world 16 points 4 hours ago (1 children)

That’s what happens when a city never gets a chance to burn to the ground and start over.

[–] ch00f@lemmy.world 22 points 5 hours ago (3 children)

I wish this map weighted streets for density. Seattle is mostly NSEW as portrayed in the plot, but the downtown core famously has two competing grid systems.

[–] ch00f@lemmy.world 32 points 23 hours ago (2 children)

Give them a Jira ticket

[–] ch00f@lemmy.world 2 points 2 days ago

When you ditch the smartphone, you make up for it on other ways.

[–] ch00f@lemmy.world 3 points 2 days ago* (last edited 2 days ago)

Only picked it up a few days ago.

I went the dumb phone route in March of 2023 because I was constantly scrolling or getting distracted while I was out with my wife. (Still use my iPhone on WiFi at home). Found that it worked well for me, but there would be the occasional question I’d have and have no way to look it up besides asking to borrow my wife’s phone.

She got annoyed, so I got the Rabbit used on eBay for $130. Got a $5/mo sim for it. I think it’s made a lot of improvement since initial launch comparing my experience to reviews. Battery life is well over a day for me, and I haven’t had it glitch out too terribly. Even the scroll wheel isn’t as bad as they say.

You just have to assume that 20% of the time, it’s entirely wrong. Like Diane Keaton wasn’t in 1989’s Parenthood, it was Diane Wiess.

I bought it under the assumption that the company would fold in a year or so, but there’s already a community rooting them and installing base Android. For $130, it’s worth whatever I can get out of it.

Edit: also aware of the glaring security hole, so no personal questions to the R1

[–] ch00f@lemmy.world 3 points 2 days ago (4 children)

Right pocket: Sunbeam F1 flip phone, space pen, moleskin notebook

Left pocket: rotates between Arduboy, Moaan eReader, Flipper Zero, or Rabbit R1

Rear right: wallet (containing car keycard)

Attached to belt: Ricoh GRIII camera

[–] ch00f@lemmy.world 5 points 2 days ago

Let’s flip the equation here.

If driving wasn’t an option, you wouldn’t live 30 miles away from your job. Driving was an option, so you did and so did your neighbors. More neighbors move in, more cars, more traffic, more lanes, more neighbors, more cars, etc.

Alternatively, you move closer to work in a town with half decent sidewalks and walk or bike in. Bikes and people take up much less space which allows things to be closer together.

And yes, cars are necessary for hauling large objects over long distances, but how many vehicles in this photo do you think are carrying more than just people?

[–] ch00f@lemmy.world 10 points 3 days ago

You also tend to not find them in the middle of cities. Texas just happens to be a car-dependent wasteland.

[–] ch00f@lemmy.world 87 points 3 days ago* (last edited 3 days ago)

The problem is not with public transportation, the problem is that the area surrounding this highway was designed so that more cars and more lanes were the only possible solution.

Cars create problems that only cars can solve.

Edit: and to add more context: those 50 different locations are all separated by massive mandatory parking lots which make them miles apart from each other when they could likely all be contained in the same building in front of a single bus stop.

[–] ch00f@lemmy.world 6 points 3 days ago (2 children)

What does a 26 lane highway have to do with cities?

[–] ch00f@lemmy.world 93 points 3 days ago (29 children)

Everybody in this photo could fit in like 4 buses

 

In my head this was Ian Kung, but I can’t find it on his channel.

The creator was trying to make a point about how broken copyright enforcement is on YouTube by basically watching cool videos and “reacting” by saying the same thing after each one loosely tailored to the content. They were all based around the phrase “my wife” or something like that.

Like “wow, what a cute lazy dog. It’s almost as lazy as my wife,” “if you think that’s a big whale, you should meet my wife,” or something to that effect.

 

I originally told the story over on the other site, but I thought I’d share it here. With a bonus!

I was working on a hardware accessory for the OG iPad. The accessory connected to the iPad over USB and provided MIDI in/out and audio in/out appropriate for a musician trying to lay down some tracks in Garage Band.

It was a winner of a product because at its core, it was based on a USB product we had already been making for PCs for almost a decade. All we needed was a little microcontroller to put the iPad into USB host mode (this was in the 30-pin connector days), and then allow it to connect to what was basically a finished product.

This product was so old in fact that nobody knew how to compile the source code. When it came time to get it working, someone had to edit the binaries to change the USB descriptors to reflect the new product name and that it drew <10mA from the iPad's USB port (the original device was port-powered, but the iPad would get angry if you requested more than 10mA even if you were self-powered). This was especially silly because the original product had a 4-character name, but the new product had a 7-character name. We couldn't make room for the extra bytes, so we had to truncate the name to fit it into the binary without breaking anything.

Anyway, product ships and we notice a problem. Every once in a while, a MIDI message is missed. For those of you not familiar, MIDI is used to transmit musical notes that can be later turned into audio by whatever processor/voice you want. A typical message contains the note (A, B, F-sharp, etc), a velocity (how hard you hit the key), and whether it's a key on or key off. So pressing and releasing a piano key generate two separate messages.

Missing the occasional note message wouldn't typically be a big deal except for instrument voices with infinite sustain like a pipe organ. If you had the pipe organ voice selected when using our device, it's possible that it would receive a key on, but not a key off. This would result in the iPad assuming that you were holding the key down indefinitely.

There isn't an official spec for what to do if you receive another key-on of the same note without a key-off in between, but Apple handled this in the worst way possible. The iPad would only consider the key released if the number of key-ons and key-offs matched. So the only way to release this pipe organ key was to hope for it to skip a subsequent key-on message for the same key and then finally receive the key-off. The odds of this happening are approximately 0%, so most users had to resort to force quitting the app.

Rumors flooded the customer message boards about what could cause this behavior, maybe it was the new iOS update? Maybe you had to close all your other apps? There was a ton of hairbrained theories floating around, but nobody had any definitive explanation.

Well I was new to the company and fresh out of college, so I was tasked with figuring this one out.

First step was finding a way to generate the bug. I wrote a python script that would hammer scales into our product and just listened for a key to get stuck. I can still recall the cacophony of what amounted to an elephant on cocaine slamming on a keyboard for hours on end.

Eventually, I could reproduce the bug about every 10 minutes. One thing I noticed is that it only happened if multiple keys were pressed simultaneously. Pressing one key at a time would never produce the issue.

Using a fancy cable that is only available to Apple hardware developers, I was able to interrogate the USB traffic going between our product and the iPad. After a loooot of hunting (the USB debugger could only sample a small portion, so I had to hit the trigger right when I heard the stuck note), I was able to show that the offending note-off event was never making it to the iPad. So Apple was not to blame; our firmware was randomly not passing MIDI messages along.

Next step was getting the source to compile. I don't remember a lot of the details, but it depended on "hex3bin" which I assume was some neckbeard's version of hex2bin that was "better" for some reasons. I also ended up needing to find a Perl script that was buried deep in some university website. I assume that these tools were widely available when the firmware was written 7 years prior, but they took some digging. I still don't know anything about Perl, but I got it to run.

With firmware compiling, I was able to insert instructions to blink certain LEDs (the device had a few debug LEDs inside that weren't visible to the user) at certain points in the firmware. There was no live debugger available for the simple 8-bit processor on this thing, so that's all I had.

What it came down to was a timing issue. The processor needed to handle audio traffic as well as MIDI traffic. It would pause whatever it was doing while handling the audio packets. The MIDI traffic was buffered, so if a key-on or key-off came in while the audio was being handled, it would be addressed immediately after the audio was done.

But it was only single buffered. So if a second MIDI message came in while audio was being handled, the second note would overwrite the first, and that first note would be forever lost. There is a limit to how fast MIDI notes can come in over USB, and it was just barely faster than it took to process the audio. So if the first note came in just after the processor cut to handling audio, the next note could potentially come in just before the processor cut back.

Now for the solution. Knowing very little about USB audio processing, but having cut my teeth in college on 8-bit 8051 processors, I knew what kind of functions tended to be slow. I did a Ctrl+F for "%" and found a 16-bit modulo right in the audio processing code.

This 16-bit modulo was just a final check that the correct number of bytes or bits were being sent (expecting remainder zero), so the denominator was going to be the same every time. The way it was written, the compiler assumed that the denominator could be different every time, so in the background it included an entire function for handling 16-bit modulos on an 8-bit processor.

I googled "optimize modulo," and quickly learned that given a fixed denominator, any 16-bit modulo can be rewritten as three 8-bit modulos.

I tried implementing this single-line change, and the audio processor quickly dropped from 90us per packet to like 20us per packet. This 100% fixed the bug.

Unfortunately, there was no way to field-upgrade the firmware, so that was still a headache for customer service.

As to why this bug never showed up in the preceding 7 years that the USB version of the product was being sold, it was likely because most users only used the device as an audio recorder or MIDI recorder. With only MIDI enabled, no audio is processed, and the bug wouldn't happen. The iPad however enabled every feature all the time. So the bug was always there. It's just that nobody noticed it. Edit: also, many MIDI apps don't do what Apple does and require matching key on/key off events. So if a key gets stuck, pressing it again will unstick it.

So three months of listening to Satan banging his fists on a pipe organ lead to a single line change to fix a seven year old bug.

TL;DR: 16-bit modulo on an 8-bit processor is slow and caused packets to get dropped.

The bonus is at 4:40 in this video https://youtu.be/DBfojDxpZLY?si=oCUlFY0YrruiUeQq

 
 

So my wife cracked the screen of her Playdate console. I got a replacement memory LCD (Sharp LS027B7DH01A), but the LCD is mounted with optically clear adhesive directly to a piece of glass which is adhered around the edges to the console’s faceplate.

The glass measures 65.15x41.64mm by 0.65mm thick. Definitely not a standard size. I can’t find anywhere to buy glass so thin and so large.

My first thought was to cut a phone screen protector down to size with a glass cutter. My first attempt failed because the screen protector I bought was actually coated in plastic on both sides. Even if I got a straight cut, I couldn’t find a way to slice through the plastic layers cleanly.

Any ideas on where to find cuttable glass sheets this thin? I could try more screen protectors, but there’s no way to know if they’ll work before buying them.

 

Let’s call it hybrid soldered memory

 

So my home office is in our basement while my wife’s is in a finished attic space. We have a mini split system, but it has to be all heat or all cooling, and many days it’s cold in my office, but hot in my wife’s office.

Thanks to a defunct chimney, I have a pretty decent path from the attic to the basement that could easily accommodate some kind of ducting.

I’d like to make a system that can push air from my office to hers or vice versa as needed. I think this would really help the house in general as cold air tends to pool in the basement.

I’ve seen plenty of ducting booster fans, but I’d like something with a speed (or at least direction) control accessible from the outside.

Does something like this exist? It would need to force air through maybe 30-40’ of ducting.

1
submitted 4 months ago* (last edited 4 months ago) by ch00f@lemmy.world to c/selfhost@lemmy.ml
 

I've been running a headless Ubuntu server for about 10 years or so. At first, it was just a file/print server, so I bought a super low power motherboard/processor to cut down on the energy bill. It's a passively cooled Intel Celeron J3455 "maxed out" with 16BG of RAM.

Since then it's ballooned into a Plex/Shinobi/Photoprism/Samba/Frigate/MQTT/Matrix/Piwigo monster. It has six drives in RAID6 and a 7th for system storage (three of the drives are through a PCI card). I'm planning on moving my server closet, and I'll be upgrading the case into a rack-mount style case. While I'm at it, I figured I could upgrade the hardware as well. I was curious what I should look for in hardware.

I've built a number of gaming PCs in the past, but I've never looked at server hardware. What features should I look for? Also, is there anything specific (besides a general purpose video card) that I can buy to speed up video encoding? It'd be nice to be able to real-time transcode video with Plex.

 

I'm an EE by trade focusing on embedded devices, but most of my work is in relatively low-power STM32 applications. When I stopped following developments in hobby kits, it was mostly Arduino Unos slowly driving I2C OLED displays.

Now suddenly, there are embedded Raspberry Pis and ESP32s doing realtime facial recognition and video feeds.

Is there a good place to look to catch up on what's now possible with these embedded devices?

Also, while I enjoy the ease of the hobby kits, I'm also interested in more mass-production-focused solutions.

 

So I need to move my server closet out of the guest room closet and into the basement so the closet can be used as a closet again.

I’ve got like 15 shielded cat6 with insulated risers patched into the back of a rack mount patch panel.

My goal is to end up with all of the existing cable extended 15’ or so to the new patch panel location, with maybe some kind of small door in the wall of the original closet so I can access the splices if anything goes wrong.

I invested in shielded cat6 when networking the house to future proof everything, and I have solid home runs to every location. I’m currently only running gigabit speeds, but I’d like to preserve the integrity of the original cables as much as possible.

With that in mind, what’s the best method for this extension? I’ve seen shielded punchdown junction boxes as well as female/female inline couplers. Keep in mind that there will be a bunch of them, so any advice on keeping things organized is appreciated.

 

The main gag is that she finds it somewhere he claims he already looked (typical), but he interprets her “magically” finding it as witchcraft.

4 panels. She looks very annoyed in the last panel.

I saw it originally on Reddit, but I can’t find it anywhere now.

 

It’s actually a super saturated solution of copper sulfate.

view more: next ›