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

> The most dangerous part of this addiction is that it doesn't feel like addiction.

I've started framing addiction as something that we feel compelled to do even when we know it has a detrimental effect on more important aspects of our life. In that respect, yes, it does feel like an addiction.

> Unlike alcohol or drugs, this is knowledge addiction - afterall, we learned about a bunch of things in those 4 hours, didn't we?

Did we learn anything? If we aren't using that knowledge, even in casual conversation, chances are that retention is very low. I'm not even talking about useful learning here, since it is pleasurable to learn something for its own sake. I'm talking about the stickiness.

Another way to think of it is: are we even interested in learning? I have downloaded the entire Wikipedia to my computer, along with Project Gutenberg, as well as various technical documentation. (Kiwix is wonderful.) On top of that I have enough books (digital and physical) to last a lifetime. I have a multitude of resources that I can tap into without touching the Internet, and accessing it is all very low resistance (e.g. I don't have to get off my ass to go to the library). So why do I even have home Internet access? Communicating with people certainly doesn't require a high speed connection.


For the purposes of apocalyptic fiction, I wonder what the overlap is between people who have an offline copy of Wikipedia and people who have only casual security or no password. I can imagine a survivor hunting around for it for a very long time.


It's more like, is it better to be the person who:

- sees a waterfall in every river, even when one is not there?

- sees the waterfall, and is resigned about their fate?

- sees the waterfall, then struggles for survival no matter how hopeless the situation seems to be?

- is completely ignorant of the waterfall?


"sees the waterfall, then struggles for survival no matter how hopeless the situation seems to be?"

You could consider that a variant of the voter's dilemma.


> One thing people go through as they age is an elevation of cynicism and general misanthropy. After decades of being disappointed when naive idealism and speculative optimism fail, one can just get down on it all.

It's even sadder when one realizes the world was always that way. The author more-or-less says as much, though they seem to suggest it is amplified. I'm not entirely sure the part about it being more amplified today true. Most of the ills mentioned existed when I was a youth, it simply took different forms and (of course) was spread by means other than the Internet. There never was a chance to get ahead because the cards were always stacked against us.

Apologies for the cynicism.


Was it a mistake?

It is easy to say that IBM had monopolistic tendencies, because they did. On the other hand, the 5100 sounds like a vertically integrated design and it ended up being extremely expensive. The Datamaster strayed away from IBM components, but was still based upon IBM software. One can blame it's failure on the IBM PC being released a month later, but in a way that would prove the point. The Datamaster had such a big head start that the IBM PC borrowed elements of it's design, while the proprietary software of the Datamaster held back its release date.

Undoubtedly, IBM wanted more control over the PC. Avoiding a completely proprietary design was probably a calculated bet, an intentional course of action rather than a mistake. It just happens to be a bet they lost.


I think their point is that computers used to defy inflation. Across the decades, computers were getting cheaper in an absolute sense (i.e. not factoring in inflation) and astonishingly cheaper in terms of dollars per unit of performance.

Even when the cost of the cheapest computers bottomed out, it likely had more to do with lower prices not making sense. At a certain point, the cost of things that encapsulate the computer and I/O (like the enclosure and screen) end up overwhelming the cost of the actual compute.


Just look at the "falsehoods programmers believe about ..." articles that pop up from time to time. There are plenty of complexities in the real world that people either don't know about, aren't front of mind when they are tackling a larger problem, or simply don't want to deal with in the here and now. Lost knowledge and new problems are part of the reason why programmers are discouraged from rewriting software from scratch and why businesses in general are hesitant to replace legacy systems that still work.


That's true, but those lists are interesting because they aren't full of things you should be learning in primary school.


True, but many of those bits would be learned in some primary schools. It simply depends upon whether they are relevant where you live. That's especially true for names, which is culturally dependent. It is also true for the culturally dependent aspects of dates/time, though there are obscure bits that are only relevant to certain disciplines.


Given Apple's reputation as of late, I was mildly shocked to learn that I could connect a SATA optical drive to my Mac with a USB-SATA bridge, right click on an image in the Finder, and tell it to burn the image to DVD. This is under the latest beta of macOS.

You can call it incidental if you want, but it generally takes some effort to ensure everything works. That's especially true when you consider how much has changed since optical drives were common.

As for other forms of disk images, such as software distribution, those are still a common thing in macOS.


iPods and AirPort Express units from 20+ years ago still work in modern macOS too. Things have been shuffled around some (iPods are now managed with the Finder instead of in Music.app) but they still work.

I would agree with the idea that they're not bothered about breaking workflows, particularly those involving command line tools, but hardware compatibility isn't nearly as bad as the internet might have one think. Source compatibility isn't all that bad either, many ancient Objective-C/AppKit codebases can be made to compile in an evening. It's mainly binaries that break.


Yeah, Apple is very weary of breaking user functionality. They'll just break your app's ability to run.


Frankly, I don't think it's practical to expect operating systems to continue to run binaries perfectly in perpetuity. It's an enormously burdensome expectation that holds development of the platform hostage.

Usually all it takes to keep one's software running on macOS is compiling against the latest SDK once every ~5 years. Depending on the nature of the app, source changes often aren't even required. As a dev I don't think that's too much to ask.


> Frankly, I don't think it's practical to expect operating systems to continue to run binaries perfectly in perpetuity.

A lot of that is going to depend upon perspective.

Take something that is coming up: Apple has mentioned that Intel application support is going to end in the next release, or about 8 years after the introduction of the M1. Eight years may sound like a good run, but there are all sorts of edge cases: software that doesn't receive updates because the publisher is no longer in business, or software developers who are providing updates under a disagreeably different business model (ahem, subscriptions). Some software may have been released Intel only after the release of the M1, simply because the developer wasn't going to test a new architecture immediately after its release.

I'm not going to pretend that I know how much software that affects, because there was a 12 or 13 year gap in my use of Macintosh. Something I did notice after my return to macOS was the absence of software due to earlier changes in the platform. An more exotic example is F-Script[1]. Not only is the project gone, but the change in the security model pretty much ensures that nothing like it will ever exist again. A more common example will be games, where only a select few will receive updates a couple of years after its release.

[1] https://www.macintoshrepository.org/25973-f-script


x86 translation will be slimmed down but remain for compatibility with the Game Porting Toolkit[0]. Their reasoning is likely that they want to limit the set of libraries that they ship x86 slices for as much as reasonably possible because each supported architecture multiplies surface area across the entire system.

It’s also notable that virtualizing macOS on macOS has now been officially supported and easy for several years, so it’s possible to just spin up a VM running an old version of macOS for software that requires Rosetta. Some kind of containerization probably isn’t a bad idea in that situation anyway, as software that’s gone so long without updates likely carries a number of vulnerabilities.

And on that note, the highly permissive state of desktop OS security as it had been for the 2000s and 2010s was never going to last. It’s been proven repeatedly that third party software must be treated adversarially, both because the big guys like Adobe can’t be trusted to keep their fingers to themselves and the little guys and FOSS projects sometimes fall victim to supply chain attacks. The OS must try to limit the blast radius where possible.

[0]: https://developer.apple.com/games/game-porting-toolkit/


> It’s also notable that virtualizing macOS on macOS has now been officially supported

FWIW, limited to two macOS VMs per host unless you hack it.


Apple unfortunately takes the opportunity of you compiling against the newest SDK to change and break all kinds of undocumented behaviors your app has been depending on, which almost always negotiates source code changes. If you’re lucky you’ll actually notice the changes; more than likely your app just appears more unstable and buggy to your users.


Making it even harder to say: the 8080 was based on the 8008. Even though the 8080 was based on the same instruction set as the 8008, it wasn't binary compatible. I assume that means the instruction encoding was different, which means those engineers probably did as much as the could to clean things up while designing the 8080.

Of course, the 8008's origins (along with the completely unrelated 4004) were outside of Intel. They were hired to design custom ICs. The 8008's architecture was dictated by a CTC terminal. While Intel designed the 4004, it was only intended to be used in calculators. Intel, and its engineers, probably put relatively little thought into microprocessor architecture until the 8080.


That should read, Trump betrays Americans. The reality is that he is destroying American credibility on the international stage, which is going to have long term effects on their ability to make agreements with other countries in the future. Standing alone is not in the interest of any nation.

As for betraying Canadians, Trump is not responsible for representing Canadian interests. I wouldn't want him to either. (Speaking as a Canadian.)


Canada doesn't have domestic auto companies, yet we manufacture auto parts and assemble automobiles destined for the US. From my understanding, this was negotiated as part of the trade deals. There is no good reason for them to desire cheap Canadian labour, weak Canadian unions, or weak Canadian environmental regulations. For one thing, Canada is known for none of those things. On the other hand, Canada had a lot of things the US wanted: access to the Canadian market and access to Canadian resources. I wouldn't be surprised if something similar happened when trade deals were manufactured with Mexico. While Mexico isn't on the same economic tier as the US, it isn't a third world nation that people like to paint it as.

As for companies looking for loopholes, it may be fun to blame it on Asian manufacturers. I would suggest that Americans take a good long look in the mirror. US companies were outsourcing assembly to Mexico long before Mexico came under the NAFTA umbrella. Quite often, at least with electronics, those US companies were using parts manufactured in Asia. Should Asian companies hold themselves back, should they avoid using the same practices as their American counterparts, just because it isn't fair to Americans? If anything, they have less reason to because Asian countries are responsible to their own citizens, not to Americans.


Your comment sounds like you are arguing with me but you are actually agreeing.

I am not "Blaming Mexico" - I am pointing out that the policy as I described it made no sense from American perspective. You are right that the American manufacturs did assembly in Mexico (form Asian components) before as well but it's the same point - an essential Asian good masquerading and benefiting from being a "north American one"


I think it is a bit more complex than that, since how Asian those goods were varied a lot across time.

Early on, it may have included semiconductors designed in the US, with manufacturing outsourced to Asia. That outsourcing may have been to a facility owned by an American company or to a foreign owned company. Then the semiconductors may have been shipped to Mexico where another company was manufacturing consumer products. Under such circumstances, can such a product be described as essentially Asian?

Of course, things changed. Asian companies took more control over product development and manufacturing. When they ran into labour and regulation making manufacturing in their own country more expensive, perhaps due to tariffs or perhaps due to their own citizens demanding better, they used the same playbook.

You're right in that it made no sense from an American perspective, but that isn't because it suddenly became cheaper to manufacture in the US. It did not make sense because they lost control of the playbook, because others could do it better.

On the whole, I agree with your point about trade being used to bypass labour laws and environmental regulations. I'll be more blunt with how I phrase it: the practice is exploitative and causes more harm than good. That said, the current American response appears to be driven by the demand for trade on their terms exclusively. Never mind that other countries may want something in exchange for their resources.


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

Search: