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

I still have my DC280. 1760x1168. Here's a sample (from the Jaques Littlefield tank collection).

https://www.w6rz.net/DCP_1004.JPG


In 1981, my first job in Silicon Valley was obtained by answering a blind (no company name) ad in the Mercury News. It was a kooky company that built burn-in ovens for semiconductors (mostly 2164 memory chips back then).

I had a lot of fun there. The purchasing manager was a Scottish guy and he had an after hours drinking club in a small conference room with a wet bar. I was only 24 years old and working crazy hours. I'd get a few beers around 7 pm and then go back to work writing 8080 assembly language code for a few more hours.

I also ended up smoking weed with the CEO and CFO a couple of times. The CFO was not a young guy. I'm not sure how old he was, but he had all white hair. The CEO gave me a mason jar full of his homegrown weed as a gift when I finished the project.

That company and even the building is long gone. It's now a Google parking garage.


I'll never forget Dennis Erectus on KOME 98.5 (the wet spot on your dial) in 80's Silicon Valley.


“Don’t Touch That Dial! It Has KOME On It!!”


MPEG-2 video is still very much alive. In the US, almost all terrestrial OTA broadcast (ATSC 1.0) and all SD channels on cable systems. Even Comcast VOD was all MPEG-2 (including HD) until they shut down the QAM version in 2023.


The way I see it, if you were to draw two graph lines showing the prevalence of H.262 and H.264 over time, it would show of course that H.262 has lasted much longer so far just by virtue of it being older yet still in active use, but the area under the H.264 line is probably already or tracking on being much larger, depending on many factors, such as how you quantify "prevalence".

I don't see H.262 as becoming completely irrelevant any time soon, so it's clearly had a hell of a run, but I expect H.264 to wind up having a similarly long tail. I am not sure I'd bet on it being longer, but I wouldn't bet against it either. I'm only of the opinion that H.264 will have one of the longest of any video codec, but perhaps not the longest.


For sure. Just YouTube alone is a vast ocean of H.264 bits.


In Europe too, for Sd via DVB-C/T2. It is however non-existent for OTT.


I was the project engineer for the Air Force Space Command / NORAD DSP satellite ground network back in the 80's. The system used the 10MB 8" Bernoulli drive and cartridges to store the early warning message traffic. The system was installed in 1988 and was decommissioned around 2005.

I'm not sure if they used the 8" cartridges all the way to 2005, but I can find out. I'm still friends with the original system maintainer. I pivoted to video compression in 1993 and lost track of the program, but we found each other on Facebook in 2010.


Little known Fabrice Bellard project. He worked with the ATSC to test the ATSC 3.0 PHY layer when he was consulting at DekTec.


Rather than potentially 1000 HN readers each spending 15 minutes on Google trying to work out what you are talking about, may I suggest that you expand that with a few plain English sentences that tell us what that means?

I have no idea what "ATSC" means, and I've been in tech for nearly 40 years now so I have a fairly good handle on this stuff.


Advanced Television Systems Committee. It's the US standards organization for terrestrial digital television. ATSC 3.0 is a new standard that's very similar to DVB-T2 (used in the UK for HDTV) at the PHY layer.


Looks like "PHY layer" means physical layer.


The article kind of disses the Intel 8085. For those of us with 8080 code bases that were never going to be rewritten for the Z80, it was a welcome upgrade. On the paper dryer process control systems I was working on in 1979, the 8085 based Intel 80/30 Multibus SBC could be dropped in for the older 8080 based 80/20 SBC with no changes and provide a significant 2.5X performance upgrade.



And again it's band-aiding the problem. Can authencesn not be fixed or what?


Maybe write to the LKML if you have some privy information?


I don't have enough hubris to assume I know things the people on LKML (or actually netdev in this case) don't. If anything, I might unicast a mail to Steffen.



looks like there have been updates since then: https://moonrf.com/updates/


It's actively being maintained by Takashi Sakamoto. Here's the commit for Linux 7.0-rc1.

https://github.com/torvalds/linux/commit/0d6dd4738dbcc32b60c...


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

Search: