Wait, are you telling me that macOS has gotten so ensh---ified that many of its users feel the need to purchase a bespoke file manager, arguably one of the most fundamental functions of an operating system?
Surely this is a very specific product for a very specific class of users? This can't be a widespread need, right? RIGHT?
(Context: I haven't used modern macOS in roughly a decade and have no idea what it's like these days)
This seems to me like a stab in the right direction.
Obviously their actions are going to be fiscally motivated at the root, but sussing out how they intend the precise dynamics to play out is more nuanced.
Thinking of this as an effort to woo the defense hawks cuts a very clear path.
While I love the sentiment, I feel like the odds of this actually ever reaching a trial are low, given the international positioning of the parties, and the... um... complex relationships involved.
Anthropic's actions seem performative. Others have already speculated on the likely audience(s).
It seems to be nearly forgotten that Once Upon a Time, business and scientific computing were more or less different universes.
The two paradigms eventually merged, but there was a problem: it wasn't really a merger. It was more that scientific computing became the implied default, and simply absorbed new and emerging business use cases over time, and actual business computing languished in senescent obscurity.
Scientific computing precepts are dreadful at business use cases (and the reverse is true as well). For an example, one need look no further than the horrors of IEEE 754 in financial calculations, which even Microsoft has admitted are a problem(1).
Now here we are. Every "general purpose" computing architecture and platform out there - from Windows on x86-64 to macOS on aarch64 to Linux on RV64 - is derived from the scientific computing lineage and paradigms.
Small wonder that modernizing and porting decades-old business software is a nightmare.
"For some reason" there are ._ files... now I'm really feeling old, that an apparently-savvy macOS user seems to be unaware of the history of resource forks and AppleDouble. That was fundamental knowledge in the subject of Mac/PC interchange not terribly long ago.
And I'm sure there's zero chance that IBM will be releasing their own Linux office product- probably derived from LibreOffice, but with an additional support line item attached- in the very near future. Nope, no chance.
Seconded. Naming an interactive language shell after ssh's older, insecure cousin just seems like begging for trouble.
I'm imagining some auditor seeing an "rsh" binary on a Linux system and dinging the system on it, and weeks of back and forth emails and meetings required to determine that, no, in fact, this is not remote shell, it's Ruby shell, and it's actually not a valid audit finding.
And, of course, that's completely omitting the binary collision issue because frankly anybody with "old" rsh installed deserves whatever pain they get.
While much of this is true- and I speak from some personal experience, here- the article also takes an unnecessarily critical tone, as if these challenges somehow invalidate the ideas behind the digital nomad lifestyle.
There's no rule that the nomad life has to be permanent, and I don't know of anybody who went into it thinking that it would be permanent (myself included).
It's very useful as a breath of fresh air, a respite, and a chance to shake up one's life in positive, meaningful ways. In many ways, it's useful to think of the nomad life like a multi-year vacation, and oh by the way, when you do decide to "go home," you have many more options for defining where and what "home" is than you might have considered possible before. I think some folks who have _only_ ever lived a settled life might be a bit blind to those nuances.
This comes back to something I mentioned elsewhere:
What's good enough for an advertiser trying to sell concert tickets is not necessarily good enough for enforcing legal prohibitions.
The location collection mechanisms built by Apple and Google that would be effective at a state or regional level within the US have been built for advertising, with secondary purposes of opt-in anti-theft. They weren't built for continuous, rigorous enforcement of legal prohibitions within a given sub-region of the USA.
I think you're asserting that e.g. 90% of TikTok users in Montana would be impacted by the ban, and 10% would find a way around. For advertisers, that's fine. For enforcement of a law? Bzzzzzz! That's gonna be arbitrary-and-capricious'ed right out of the courtroom doors.
Running with the billing address example... so to circumvent the ban, all one would need is a prepaid phone plan. Service addresses are collected for those, but they're basically unused and there's no incentive on the consumer end for them to be accurate.
Even on post-billed plans, getting the billing address from the mobile carrier to Google requires a degrees of cooperation that is not currently in place. Apple may have an easier time in the regard, but then again they're not likely to cooperate either.
I'm a bit perplexed that there seems to be minimal discussion on the complete technical absurdity of this ban.
Within the USA, there might _possibly_ be sufficient technical infrastructure available to block app downloads at a national level. Maybe. And leaving aside the myriad circumvention routes.
But at the state level? It's simply not there in the way that the legislators think. Application-level data? Turn off location services. GeoIP? Nice try- mobile carriers don't reliably egress in the state from which the customer traffic originates. E911? Protected by other laws. Cell tower location? What about folks near state borders, and there's no reliable vehicle to get that data to app store operators right now anyway.
What's good enough for an advertiser trying to sell concert tickets is not necessarily good enough for enforcing legal prohibitions.
Effectively, to enforce this would require cooperation between government agencies, mobile carriers, and app vendors on a scale that has not be done in this country before- and with two of the three parties not even remotely interested in such cooperation.
Any of the late 90s / early 00s RISC platforms would be good for this. You could easily grab an AlphaStation, Sun Ultra, or pre-G3 PowerBook for such a purpose, and within your price range. Perfectly adequate for most non-browser tasks, and fun to learn if you're coming from the PC world.
Even the G3-G5 PowerMacs aren't really usable for modern web browsing anymore. The vanilla FOSS browsers aren't reliably building on them anymore, and even the "keep it usable" browser projects like TenFourFox are just barely scraping by performance wise on modern sites.
Note that your distro choices will be limited with these, but they all have at least a couple still available.
> To paraphrase Bob Metcalfe, if the browser reduced operating systems to “a poorly debugged set of device drivers”, then the cloud is reducing the dev machine to a poorly debugged set of environment mocks.
A certain breed of application developers love to spout this tripe until the operating system and/or the dev machine and/or the Internet connection don't work. Then queue days of tearful agony and whining to the tune of "I need this to do my job!"
I can second the legacy and reliability assertions. My experience with z/Arch was more recent- and it's a very different world from the modern cloud CI/CD Linux git Dev[Sec]Ops thing- but the reliability and legacy support immediately impressed me. A single z/Arch rack is basically a cloud in a box - get it power and network connectivity and you're golden. Other vendors can offer that though. The legacy support is another story; I watched an NGiNX proxy and a custom financial reporting app from the late 70s running side by side on the same box, and that's when I understood the additional dollars.
My introduction to Forth was tinkering first with Sun SPARC machines in the late 90s and then PowerMacs in the early 00s.
At the time, I had no idea that it was a discrete programming language; it only registered in my mind as part of the OpenBoot/OpenFirmware environments. Then I ran into the FreeBSD bootloader and things finally clicked. "Aha," I thought, "this is an actual programming language." But what made it so popular for the early boot process, and where else was it used?
The modularity was stunning. It was easy- almost absurdly so- to build complex code up from a series of tiny individual functions. That, coupled with the minuscule interpreters and simple stack-based approach, made perfect sense for situations where developers need to perform complex tasks with minimum of storage overhead, and with portability as a first class citizen.
I find that it's a good fit for quite a few things, but if you're looking for a specific example: clustered Java application stacks, like ELK or Hadoop.
Zones, crossbow networking, SMF, and ZFS w/ BEs all working seamlessly together is a fantastic combination for easy-button admin of low- or zero-downtime clustered applications.