transportation government operations natural resources community development education & social services agriculture international affairs science & space and energy

...anxiety rises.

Pretty cool to see all 6 layers, paste layers, and adhesive layers as well. I've always wondered how the cake was made and if big projects do/could use KiCad. Seems like a lot more work relative to those Single Layer PCBs on YouTube for things like emulators and custom PCBs. Glad I now know for sure, that I can't do this.

IMO, rounding for cash purchases only sounds worse than keeping the pennies.

But with 5 trillion dollar companies these days that are "worth" more than the entire GDP of Germany, why not. It's not real. It's just a number on a computer at this point.

I'm going to say this because I think you might not know this, but also because I think many others might not have thought about this:

Almost always, a programming language is UI agnostic. Swift SDK for Android means: You can now write Android Apps in Swift. This doesn't magically include Apple's components / SwiftUI. When you write code for a platform, specifically an SDK for an OS, all you do is expose that platform to that language.

So, as long the SDK/bindings are there, a new "Window" means whatever a the OS thinks is a Window. A Button is what is defined (or exposed/binded to) as a Button in Android.

Swift was sorta released for Windows: a new Window looks like a generic Win32 Window. The same one you would get if you used C, C++, Rust, etc..

All your examples are GREAT examples to explain how this works: - Flutter has "Cupertino" to allow people to use Flutter to make Apple apps, and not have to learn names/methods/interface of the native Apple UI. - React Native: A LOT of work was put in to make/bind Apple native objects to a React component. And the same for Android.

So again:

The Swift SDK for Android means you can write your Android apps in Swift. The same apps you might of wrote in Java or Kotlin, you can now use Swift. Meaning whatever it looked like in Java/Kotlin (using native api's), it would look like in Swift.

The SwiftUI, Apple's component library written/exposed to Swift, is something completely different.

1) The code that is running is not what's presented; it executes (non-transpiled) vanilla JS.* Why not just show that?

2) Removing the box shadow massively makes the two closer in performance.

3) The page could just be one sentence: "Reflowing the layout of a page is slower than moving a single item." GPU un-related.

---

*Code that actually is running:

```js

        , u = t => {
        h && clearTimeout(h),
        l.forEach( (e, s) => {
            const {top: o, left: n} = m[r[s]];
            t ? (e.style.transform = "translate(0px, 0px)",
            e.style.opacity = "0.7",
            e.offsetHeight,
            e.style.transform = `translate(${n}px, ${o}px)`) : e.style.transform = `translate(${n}px, ${o}px)`,
            e.style.top = "",
            e.style.left = ""
        }
        ),
        t && (h = window.setTimeout( () => {
            l.forEach(e => e.style.opacity = "1")
        }
        , 500))
    }
        , d = t => {
        y && clearTimeout(y),
        l.forEach( (e, s) => {
            const {top: o, left: n} = m[r[s]];
            e.style.top = `${o}px`,
            e.style.left = `${n}px`,
            e.style.transform = "",
            t && (e.style.boxShadow = "0 14px 28px rgba(239,68,68,0.45)") // REMOVING THIS LINE = BIG DIFFERENCE
        }
        ),
        t && (y = window.setTimeout( () => {
            l.forEach(e => {
                e.style.boxShadow = "none"
            }
            )
        }
        , 500))
    }
           

Honestly, the "could of" is more of a "sometimes I write how I sound" thing, but anything else, is more of a middle of the night brain mush.

I actually re-wrote that bottom part at least twice because I had a lot to say, but didn't know how to say it concisely. As I was writing it, I kept having less and less confidence that any readers would have prior knowledge about I was writing about (ex: Plex, HDHomeRun, TiVo Edge), so I kept defining or explaining things in parenthesis and re-ordering the sentences; so at one point I just had to say, good enough, click reply

I hate lengthy/wordy comments that coulda' () been just a couple of sentences, but I also love to explain things in a way that a wide range of people can comprehend, so it's a battle at times. (this reply is a good example...reply)

I felt like they had consumer awareness at one point. Maybe if they went with there own premium streaming service, as oppose to only trying ad-based streaming services (like Pluto) OR continuing to try to make money charging people monthly for a subscription to use a device they first have to purchase.**

Instead they kept the old business model and went to more of a business-to-business service oriented offerings. Selling metadata, APIs, TV Guides, Car infotainment, all oddities IMO as most IPTV providers like to use turn key solutions.

I actually use the Tivo Stream 4K as my smart device. Works great, gives me 4K, can download Android TV apps, and is cheap $35.

Not a fan of ad-based TV (which is the Tivo+ thing, like Pluto, etc...), but I use it mostly for YouTube, Plex, etc.

--

*: My Plex server uses my HDHomerun for live tv; TiVo could have been both if it was more open. A TiVo competitor to Plex's Pass + Live TV service could of been there subscription revenue, and a TiVo competitor to HDHomeRun's devices could of replaced their DVR revenue. They could take the Tivo Edge, open it way up (as the HDHomeRun takes cable and give you actual m3u8's; this lets you decide where you view or record TV, and makes the device actually useful for commercial deployments as well (offices, restaurants, dorms, hotels, etc...). Pretty much: add features similar to Plex (i.e. combining my OTA/Cable recordings with my local media) + Plex's Live TV (Tivo already has the richest data and a sleeker guide) and combine the Tivo Edge CableCard and OTA in one device. This would appeal to many users, bring the hardware price down as it's one model, and provide them with both revenue streams like they are used to.

>> "Hotwire is sort of vanilla rails and it enables you to create very modern experiences with content live updating through web sockets and it is basically a one liner to setup."

My point was that web development isn't complex, but the core is simple; but modern web development is.

Your "Hotwire is sort of vanilla rails" statement is a perfect example.

What you claim to be simple, is a big list of tooling, web-sockets included, integrated together. The end result is using it might be a "one-liner", but that doesn't mean it's simple. And that's OKAY. Because simplicity should be the standard; and adding things, like sockets for live updates, should be something you explicitly enable (with modern web-apis, its definitely simpler than it used to be, but that doesn't mean its simple)

Tooling isn't the problem: The complexity is inherent to modern web development. You see similar "hidden" complexity in other frameworks like ASP.NET, and GUI desktop frameworks as well.

If you're using Rails as an API backend with React handling the frontend, it's almost a completely different application architecture than a traditional Rails monolith. So the list of tools (Vite, React, Prettier, etc..) is almost for a completely different problem (again, unless you use Rails for FE; if you want to use Rails for Frontend, use Rails for Frontend; not a fan of the mash-up at all.)

The real issue is learning methodology: A lot of developers today start their careers with frameworks (point 4) before learning the fundamentals of the web (points 1-3).

HTML for markup.

CSS for styling.

Learning server-side logic (e.g.: can POST and can return a completely different page at the same URL) and databases for dynamic content.

Then, JavaScript for interactivity.

Embrace the tools: Each tool on the list (Vite, Tailwind, etc.) exists for a reason, and they're all necessary for a modern web application. Saying there are "too many" is an amateur take on the reality of the ecosystem.

> git checkout $(git rev-list -1 --before="YYYY-MM-DD" master)

but thought I found a shortcut - which turns out is not really one, and like you said: confusing.

I can't edit my post, but in any case; the point being: it would be nice if import statements are closer to "github.com/google/uuid@YYYY-MM-DD" or in this case you can pass a date to version: "YYYY-MM-DD" and the library would run the uglier nested command above to import the proper version.

ex: you can use this to checkout a repo @ a specific datetime: > git checkout 'master@{2025-05-26 18:30:00}'

just doing my share to help people steer away from another leftPad disaster (or the xz apocalypse that almost was...)

macOS Ventura 13.7.8 | macOS Sonoma 14.7.8 | macOS Sequoia 15.6.1

iPadOS 17.7.10 | iPadOS 18.6.2 | iOS 18.6.2

Usually, its multiple CVE's in a security update.

Examples:

- https://support.apple.com/en-us/122375 (macOS Ventura 13.7.5)

- https://support.apple.com/en-us/122718 (macOS Ventura 13.7.6)

- https://support.apple.com/en-us/124151 (macOS Ventura 13.7.7)

--------------------------- References/Sources ---------------------------

[0] https://support.apple.com/en-us/124925 -> https://support.apple.com/en-us/124929 | (124925 -> 124929)

https://support.apple.com/en-us/100100

https://nvd.nist.gov/vuln/detail/CVE-2025-43300#vulnConfigur...

MS OneNote* for all longer term to-dos, or writings I wish to archive.

Paper or notepad.exe for ephemeral to-dos.

: one large synced notebook with folders, sub-folders, and w/e nested levels it offers, but I use search anyway.* *: this can totally be replicated with documents/files, folders, and a git repo. (and maybe some markdown editor)

: I don't know of any open source license ones that don't allow someone to sell hosted cluster. Even AGPL, which is copyleft, allows it; so long as the hosted version is either: the same as the open-source version, or it's version is also open-sourced.

I've been working on one in Typescript (with eventual re-writes in other langs. like Rust and Go), but it's difficult even coming up with conventions.