Hacker Newsnew | past | comments | ask | show | jobs | submit | EvanAnderson's commentslogin

Unless it has changed recently you need to have a minimum qty. license purchase. Any good reseller will sell you the one license of LTSC and pad the rest of the order with the cheapest qualifying license in the catalog. (In the past it was DVD playback licenses at a couple of bucks apiece, for example.) I was able to get licensing for my father's sole proprietorship DBA from a big name reseller w/o furnishing any kind of business-related docs and paying with his personal credit card. (In his case it was Windows Server and CALs, but the premise is the same for LTSC.) You'll probably have to talk to a sales gerbil but it's imminently feasible.

The new HP PCs I've deployed recently did not have current Windows 11 builds installed. I tend to think OEMs are being slow to update their master images.

Isn't the deliberate misspelling of words in trade names used to create names eligible for trademark protection?

I find them horrible cringeworthy, too. Names with letters pronounced phonetically (e.g. "EZ"), sound-alike vowels (e.g. "Lyft"), and substituted consonants (like the K for C) irritate me a lot. (I'm an angry pedant and I know it...)


The lobbying by the AMA may go back to the 80s, but the 1997 "Balanced Budget Act" set the limit on residency slots.

Nice background: https://www.washingtonexaminer.com/opinion/1692395/thanks-to...


If you're not familiar with how teletype machines worked you might enjoy it. There were early units that were purely electromechanical. It's really cool.

Usagi Electric did a nice video if that's your kind of thing: https://youtube.com/watch?v=sSiVYgot9SI

I think the video does a nice job of showing the mechanical components that encode the keypresses and generate the 45.5 baud serial output. The printing side isn't given quite as much coverage but you do get to see close-up views of it in operation.


Neat! I remember this thing from when I was a kid. We didn't have an Imagewriter printer so it wasn't an option for me. Having a scanner back in those days would have been amazing.

There is a nice reverse engineering of the Thunderscan here: https://beefchicken.com/retro/thunderscan/


I'm still running my 2006-era fork of ttrss on a VM that's so old I'm ashamed to say what it is. I had to stick a proxy in front of it 10+ years ago so it could handle modern SSL. I can't imagine using the web without it.

In the world I'm living in, corporate IT, there's a ton of COM and SOAP. I don't see COM running across the Internet (other than thru VPN tunnels), but I see a ton of SOAP for interop with third-party interfaces. Pretty much any of the "enterprise" Java-based apps I work adjacent to have SOAP-based interfaces.

COM is alive and well in the LAN space, too. I see it in industrial automation under the guise of OPC, fairly frequently, too.


Also, providing and consuming a basic COM interface is quite easy with Miscrosoft's development tools. This is not true in other ecosystems.

So COM did not fail as a standard, it just failed to conquer the whole world. It's doing fine though in its natural habitat.


I have a different experience writing and using COM with C++. I remember ugliness around reference counting, dealing with the literally dozen of methods of defining a string and having to coerce them into BSTRs and having to deal with variant types that were a weird C union type.

I remember going to a class at Embedded Systems Conference that showed how to implement a COM interface in assembly on a microcontroller. Was cool, but I had no use for that, although we were using COM/DCOM at the higher levels.

That sounds cool, though. Seeing protocols/formats/algorithms laid bare in assembly code makes them comprehensible in a way that I don't get from high level language implementations, where I have to either be content in just hand-waving away understand any "sugar" the language itself implements, or also having to understand the language's contrivances on top of whatever the core thing is I'm trying to understand.

Thank you for sharing your experience. I am just now realizing that just because I don't hear about SOAP very often doesn't mean it isn't still around.

> Example of inherent client-side limitation would be how Youtube works: > ...

I thought about this problem a long time ago but never did anything substantive with it. I guess I'll articulate it here, off-the-cuff:

People used to post a "blogroll" (and sometimes an OPML file) to their personal blogs describing feeds they followed. That was one way to do decentralized recommendations, albeit manually since there was no well-known URL convention for publishing OPML files. If there was a well-known URL convention for publishing OPML files a client could build a recommendation graph. That would be neat but would only provide feed-level recommendation. Article-level recommendation would be cooler.

One of the various federated/decentralized/whatever-Bluesky-is "modern" re-implementations of Twitter/NNTP could be used to drive article-level recommendations. I could see my feed reader emitting machine-readable recommendation messages based on ratings I give while browsing articles. I would consume these recommendations from others, and then could have lots of fun weighting recommendations based on social graph, algorithmic summary of the article body, etc.


Not the parent poster, but that looks really promising.

I want to get Immich up and running for my personal workflow. I shoot sports stuff regularly that I want to share along with personal photos I do not. Right now my workflow is frustratingly manual for this process. Having the "share with the public" functionality right beside my internal workflow would be a dream.


Me too. I've been wanting this with immich.

Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: