joshumax

> On Aug. 3, 2022, one officer sent a memo to the acting police captain requesting the couple's home be marked as a "swatter house." The captain declined, saying it could cause a "complacency issue for responding officers.”

You'd think they'd be more concerned about constantly wasting time and resources to constantly send out SWAT to some random couple's house twice a week.

Ah, well that makes a bit more sense. Admittedly I haven’t really looked into Jev and thought it was an open decision model rather than a proprietary product from TypeSafe.

I’m looking at the LLM-generated SECURITY.md and this thing seems to pump a LOT of information back to some place called TypeSafe AI. That and the AI-generated comments from OP here make a few red flags go up for me.

Not just regular nitric acid either, but red/white fuming nitric acid in many cases!

Back during my teenage years I used to make the stuff for decapping projects and amateur rocketry by grabbing the ingredients from our local hardware store and distilling it in a make-your-own-moonshine kit I bought off of craigslist.

Worked great up until the police were called because the store employees thought I was making bombs. I hear heating up sulfuric acid is the better way to decap epoxy chips nowadays.

Ooh great timing! I've been working on a custom firmware replacement (Yocto base) + FOSS control app for existing smart telescopes with plans to release a beta in the next month or so. Currently I'm building out Support for the ZWO Seestars, Dwarf Mini/II/III, Vaonis Vespera, and Unistellar Odyssey (this one's very WIP though). Also working on a nice HAL and plugin system to make porting the CFW to new devices as simple as possible. To tie it all together the firmware also has an Alpaca server running on it.

Currently the state of software development for these smart scopes are...not good. I even wrote about the issues years ago when I "jailbroke" my Seestar S50[1]. With a proper open source solution + better quality gates, it's finally turning into something usable for us power users. I'll give ZWO credit for one thing though, at least they themselves finally admitted defeat and added native Alpaca support in the end.

If you do release your open source Seestar alternative, let me know and I'll write a HAL driver for it.

1: https://www.cloudynights.com/forums/topic/900861-seestar-s50...

There are several “AI” deconvolution tools to remove stars which work exceptionally well: two of the most popular ones being StarNet and RC-Astro’s StarXTerminator. I’m willing to bet that the author used the latter for star removal as it’s become something of a standard in the astrophotography world.

I used Astra on one of my old observatories (an aging Explora-Dome) and I can say it's definitely a very nice experience compared to "legacy" tools like ACP from DC3. That being said, however, it kind of sits on the lower end of functionality compared to existing commercial observatory control offerings like Starkeeper's Voyager platform, especially when it comes to advanced scheduling features and scripting. Still, for basic needs it's nice to have a decent open source alternative in a very niche ecosystem.

I think GP was mostly referring to astrophotography when it comes to light-polluted areas. I live in a bortle 9 area (downtown) and unless I bring out my 20" dobsonian I'm mostly visually limited to double stars, planets, bright clusters, and extremely bright emission nebulae such as M42. With modern LED broad-spectrum lighting, skyglow definitely becomes a major issue, especially for broadband targets like Andromeda.

However, I've been able to capture stunning images (and an APOD) even in broadband within my city using dedicated astro cameras and modern gradient processing techniques quite easily, so we're definitely living in the golden age for EAA if you'd consider that as an alternative.

Funny I should see this on the front page, since I’m one of the (likely) few lunatics on HN who rents a pier at Starfront. So far I can say that they’re definitely one of the better offerings when it comes to remote observatories. Shipping my gear and setting it up was a tad painful, but once everything is operational the rest is a breeze. Plus the onsite staff are very responsive when it comes to servicing my CDK (cleaning/upgrades/resets/etc.)

For those who want to try telescope colocation on a budget, they also have a relatively cheap ZWO Seestar pier option. I haven’t given _that_ a try yet, but I’ve heard good things about it on Cloudynights.

Yeah, I've always been surprised[1] when people come out claiming to be Satoshi but ignore this very blatant writing style in their own texts. I haven't really interacted that much with them online and both the double spaces and the British spellings struck out to me and a few others years ago.

1: https://news.ycombinator.com/item?id=15917598#15919288

Yes, it works, but there are some issues.

The first one being that the SoC configuration runs in DS-compatibility mode which does not expose all of the available RAM in the DSi, and nds-bootstrap won't properly redirect I/O requests to the external SD card, which means you either need to embed the rootfs in the NDS ROM which won't persist changes, or use a flash cart and run the DLDI build instead.

I very fondly remember this project when I was growing up too, and I credit it with sparking my interest in kernel development.

When trying to port some industrial control software to DSLinux, I ran into some bugs around how the SLOB allocator behaved under memory pressure. One of my patches landed upstream, even though SLOB is deprecated now. Still, as a kid starting out in the embedded space, it opened my eyes to the joys of hacking around with homebrew.

Fun fact: a modded DS still powers a large part of my local observatory's equipment.

Sorry, I think this might tangentially be my fault. I know someone who works on the GitHub team and let them know about the situation via IM. A few minutes later both the account and the issue disappeared.

If by "lens flares" we're referring to the 6 spikey lines getting from the stars, those are known as diffraction spikes and are a result of the 3 spider vanes holding the secondary mirror in front of the primary mirror cluster at the center of the optical axis. As light enters the primary mirror cluster in the JWT, bright points of lights such as stars have visible aberrations due to the position and orientation of these vanes. In the JWT which uses 3 of them, their orientation creates this 6 spike diffraction pattern. In the case of the Hubble telescope, which is based on the RC telescope design, it uses 4 vanes which creates a 4 spike diffraction pattern instead.

Funny I should see this on the front page of HN the day before I finish my Stellarium port for Nintendo Switch [1]. Unfortunately a lot of the UI code in the 1.0 release made it harder to port so I'm currently basing the Switch version on the 0.xy tags, but it's still a great accomplishment for the Stellarium team!

1: Unless I get approval from Nintendo AND Noctua you will need an RCMed Switch with Atmosphere to run it.

Funny how two people can hack two separate home phones to run DOOM without realizing it until after the fact. For perspective, I posted a blog article about modifying a CaptionCall phone to run DOOM at the same time [1] as this was posted! What a unique coincidence!

1: https://joshumax.github.io/general/2021/08/11/running-doom-o...

Some of the reviews also seem comically fake, take for example this 5 star review for the "Airpod Pros":

'You will love these earbuds . I mainly use the wireless earbuds, I am very satisfied in all aspects. These earbuds also have a solid voice for music. They are easy to pair. More than enough scope. These earbuds work very beautifully. Awesome battery life and clarity. These earbuds are the most convenient and comfortable. I love these earbuds , I already want another pair. Buy them. You will love these earbuds .'

Manjaro on the PinePhone currently has 2 branches. The first alphas used Plasma Mobile and another branch of alphas use Phosh. Work on the Plasma Mobile builds seems to have slowed down for Manjaro ARM, partially likely due to some UI instability and also because the Phosh experience currently feels more polished.

I don't expect much from anti-malware companies, but this is one of those moments that made me absolutely dumbfounded that someone actually thought embedding an entire un-sandboxed JS engine with SYSTEM privileges was in any way a good idea. I actually had to get out of bed, open IDA, and start a Windows VM just to check that this wasn't some sort of elaborate hoax!

This isn't some MIDI parser logic, it's an entire JS interpreter that can parse DOM elements! How in Earth did this even get pushed out to a release? Did we learn nothing since the last time [1]?

1: https://bugs.chromium.org/p/project-zero/issues/detail?id=12...

I was only around at Codeweavers for a part of this huge undertaking, and only contributed a small part of the 32-on-64 MacOS patchset, but I must say this was one of the most impressive feats I've seen coordinated using mainly nothing but email and IRC for communication.

Everything from thunking layers to calling conventions to inline assembly in the Wine codebase had to be redesigned for this release of Wine; an absolutely massive proposition. Ideas such as dynamic binary translation and running Win32 executables in the MacOS hypervisor framework were considered, and some ideas I tried while hacking Wine gave me insight into other projects I hack on such as Qemu and LLVM.

In short; props to everyone who worked on this! It was a long time in the process!

What are you referring to regarding pthread_create()? Last time I checked I thought that it would return an undefined thread* only when giving a nonzero return code, which while certainly isn't handled in a lot of multi-threaded applications could be checked before anything else is done with the newly created thread.

Wow, I remember booting up your port on my XE to run a Minecraft server on my Google glass during a vacation; thanks for all your hard work making pmOS better!

FWIW I maintain a port of Debian stable for my XO-1 with IceWM and it's extremely resource-light on the aging OLPC hardware. I'd be happy to throw up the build scripts on GitHub if anyone is interested.