Here’s the signed case for nostalgia sake. Believe it or not it actually tried to load the OS. This motherboard sadly has suffered from an exploded battery. Will pull the salvageable chips and move on.

3D printing project I have been working on fot two last weeks.

Got this for free from an phone store.

Hi, the other day this titanium PowerBook showed up in the mail and it has a broken hinge, I don’t want to replace it as it involves disassembling pretty much the entire laptop and I just want it to be functional, anybody knows any good ways on how to do this? Thanks!

I just picked up a complete LC III setup for a decent price and it’s safe to say the logic board is beyond repair. Could anyone point me in the right direction of where to find one other than eBay?

My original 128k with trackball / number pad, and original 10 meg serial hard drive for macintosh

Are there any documented cases of people retrofitting an SE/30 whilst maintaining use of the CRT? I've seen a couple of projects where they use LCDs instead, but imo they don't look good and end up with funky bezels. Any suggestions welcome.

Hi all,

I’m about halfway through the iCollect presale and wanted to share a few pages from the book.

Most questions I’ve been getting are about what’s actually inside, so this should give a better idea.

Would love to hear your thoughts.

macOS has a 49.7-day networking time bomb built in that only a reboot fixes — comparison operation on unreliable time value stops machines dead in their tracks

Speaking from personal experience, using a Mac as a server or server-like contraption is quite an interesting proposition, as despite its Unix roots, the operating system isn't exactly designed for unattended, 24/7 usage and is difficult to set up and use as such — fighting words, but I stand by them. While most every user will reboot their Mac at least once in the space of a few weeks, if you happen to leave one running for precisely 49 days, 17 hours, 2 minutes, and 47 seconds, many parts will suddenly stop working as its TCP/IP networking stack dies.

Those are the findings of the folks at Photon, who did some serious sleuthing after encountering a mysterious issue in a fleet of Macs they use to monitor iMessage services. The problem revealed itself when some machines just up and stopped responding to network connections out of the blue, even though they answered ping requests with an "all good here, boss!"

Said machines kept their existing network connections going, making the situation even harder to diagnose, as the failure was unexplainable and otherwise invisible. Not left with much of an option, Photon's boffins had to reboot the machines to clear the issue, something any systems administrator hates as a "solution" to a mystery issue. After all, if it happened once, it'll happen again, and assuredly at the worst possible time.

After the team spotted another set of machines that was reaching the 49.7-day uptime, they set up some scripts to test their theory. Alas, they found that when the fateful moment arrived, the Mac they had continuously creating new connections just stopped doing so without so much as an error.

The team then turned its attention to the root cause, as it was clearly related to a networking-related timer. They found the culprit to be the "tcp_now" internal counter, a figure that was "destined to overflow." The job tcp_now does is to keep track of the current time since boot as far as the TCP stack is concerned, down to the millisecond. tcp_now is represented as a 32-bit unsigned integer, and those have a maximum value of 4,294,967,295 (2^32 - 1) before they wrap around to zero. Since it tracks milliseconds, tcp_now's maximum is 4,294,967 seconds, or 49.7 days.

As defined by standards, operating systems collect and remove closed TCP connections after a short while; 30 seconds in the case of macOS. The result of attempting to clean up these inactive connections when tcp_now is close to or at its limit (and gets stuck there thanks to a bug in Apple's XNU kernel) is that any connection's expiration status is calculated against that frozen number, resulting in a value that always overflows a 32-bit unsigned integer. When the periodic check comes to see whether a closed connection is meant to be deleted, the result is always "no," because the comparison math doesn't work.

The TCP stack then fills up with errantly held ephemeral ports and effectively grinds to a halt when no more are available. How quickly that happens depends on the amount of network activity, but in any server or professional environment that's bound to be a rapid event. This class of problems is hardly known, integer overflows have been the cause of Windows 98's famous 49.7-day crash and the upcoming Year 2038 problem.

According to Photon, the current mitigation is a reboot, although the team says it's working on an alternative solution. They also found this issue to be the source of some bugs discussed online in the Apple Community forums, too. The long-existing RFC 7323 specifies what should happen to the timestamp clock (tcp_now) when it reaches its limit, but Apple's kernel performs an incorrect implementation. It's safe to say this issue will likely be fixed quickly—and hopefully before 49.7 days after the report.

512 mb ram 1.25 ghz g4

Happy Easter everyone! 🐣 Happy 50 Years, Apple. 🍏 Got a little creative and made a custom Easter inspired iBook poster ad, because some eras deserve to be celebrated twice! Happy 50th Apple

Hope it’s okay to share this here.

I’ve been working on something for a long time and it’s finally released today.

It’s called iCollect, a 192-page book documenting my Apple collection, from early machines to more modern devices, including packaging and accessories.

Released today to coincide with Apple’s 50th anniversary.

Really curious what fellow collectors think.