"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.
I remember when creating a zip file from the finder filled it with a bunch of resource fork files that confused the hell out of anyone opening it on windows.
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.
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.
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.
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!"
reply