ninefathom

This is a very long-winded demonstration that the shareholder-driven philosophy of "we must keep growing at all costs" is not sustainable.

//confused noises//

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.

(1) https://learn.microsoft.com/en-us/troubleshoot/microsoft-365...

Very interesting to see this pop up on HN just after I spent a few days making Alpine/m68k a thing.

(just a personal tinker project - don't look for it upstream any time soon unless I get extremely bored)

"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.

//rolling my eyes into the back of my head//

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.

This thing is pure political theatre.

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.

See also https://www.openindiana.org/announcements/openindiana-hipste...

//happy dance//

... That is all.

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.

what do you use OpenIndiana for?

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.

A developer is surprised that improper electrical infrastructure causes systemic computer malfunctions. Surprised enough to write an article about it.

I feel like this just perfectly summarizes my early years in the tech field, back when I was a screwdriver jockey and spent my afternoons diving under desks. "Why yes, person who gets paid more than twice what I do- spilling a chai latte on your laptop keyboard does mean that it has to go away to a computer hospital for a bit, and no, I cannot magically go back in time and make a copy of all of your important files on an external hard drive for you."

To the author: no hard feelings- I love devs. But just like you might be surprised at the person struggling to write a simple be five-line bash script, sometimes the hardware-oriented folks are surprised at what doesn't occur as an obvious issue to others.

I'm glad to see interest in this functionality taking off in Linux-land. I think there are one or two other projects with similar goals (i.e. implementing BE selection on Linux) and it might be time for me to do a side-by-side.

This capability was something of which the lack on Linux has long puzzled me. Solaris actually implemented a very early incarnation of this ability (called "live upgrades" at the time from its original use case) back in the early '00s- in Solaris 8, and on top of UFS no less, if I recall correctly. It evolved over the next decade first adding ZFS into the mix, then finally morphing from the early "live upgrade" stuff into the full "boot environment" concept around 2010 with Solaris 11. FreeBSD implemented it around 2012, in the early days of their ZFS work. More than a decade ago. That puts Linux at least ten years behind the curve here, and arguably closer to twenty.

I'm a fan of using the right tool for the right job, and jumping freely between Solaris (or OpenIndiana nowadays), Linux, and FreeBSD for any given deployment is par for the course. Until now, all other things being equal, FreeBSD or Solaris would often win out if minimizing downtime* was a much higher priority than ease of replacing admins. Assuming that BE support in Linux matures quickly, that calculus has now swung strongly in Linux's favor.

*Re: minimizing downtime, if somebody is puzzled as to what I mean, think of the last time that you had a Linux installation fail to come back up to full operation after a borked round of package upgrades. It's not often, but it does happen occasionally. Now imagine that the time you spent getting back up and working, whatever it might have been, was reliably less than sixty seconds. Now imagine it's 2am, you're not even fully awake following a panicked phone call from the operations night shift, and your job hangs in the balance. Makes quite a difference.

xterm? Never heard of it.

In all seriousness though... sorry, friend - that's a negative re: xterm vt420 compatibility.

Quoting from the [current] author's own website at invisible-island.net/xterm/ :

"[xterm] also implements most of the control sequences for VT220, as well as selected features from other DEC terminals such as VT320, VT420, and VT520."

That "selected features" bit is why I keep the real glass one around. Paging is probably the most deficient area that I really notice.

OpenVMS on VAX. There are plenty of terminal emulators out there that are 99% VT420 compatible. On *nix it's rare to notice that remaining 1%, but on VMS it's noticable.

These types of things always make me chuckle. There are many aspects of '80s and '90s computing for which I'll wax nostalgic, but the monochrome CRTs are not among them. One could hardly have designed a better instrument for destroying eyesight, and I wince every time I need to pull out my lone remaining VT420 for anything.

I don't necessarily think that AWS is overly complicated. What I do think is that the entire ecosystem of tools is very powerful, and often times finding the "easy button" for a given task (and there usually is one) is far more time-consuming than it should be.

Many a time* I wished that Amazon would have a single easy-to-find documentation page listing common use cases and the de facto standard third-party tool (and there usually is one) to make a given case easier.

Fun side note: as a security professional, I cannot even begin to tell you how many times I've heard app owners claim that "AWS handles security for us" or some variation thereof.

*It's been a few years since I messed with AWS in depth; for all I know such a page may exist now.

This is my concern as well. The idea here seems to be that the thing that offends the least must be fact.

This behaves very differently for falsifiable vs. non-falsifiable information, but the end result is not something in which I'd place much stock either way.

Edit: to be clear, from Twitter's perspective, this is excellent, i.e. this is precisely what a revenue-motivated entity would want. It's the rest of the world that I'm concerned about.

I've had the privilege in the past of working with a small number of Irani technology professionals, and I found these particular individuals to be some of the most capable and well-rounded in the entirety of my experience with the global technology field.

The idea of any of those individuals sitting in prison for political reasons turns my stomach.

which if true, means they don't need a license. (And if false, then they're in violation of the existing licenses anyway.)

Precisely my thoughts; either they're already violating the attribution requirements of such a license, or it's under Fair Use in which case the question is moot. There's no need to put them doubly into failure of compliance.

I'm not an attorney; I have worked professionally with IP policies and licenses for a number of years. I generally give the following suggestion to developers considering FOSS licenses: once you've put your code under an open license, assume that you no longer own today- you only own tomorrow.

What I mean by that is that once the source code is out there under a given open source license, it's best to consider it a total loss until the next time you change the code. Of course there's always the right to challenge and litigate, but this is often time-consuming, expensive, and an uphill battle. I can't even put a number on how many times I've dealt with teams who love the "warm fuzzy" of creating an open source project, but get apoplectic when they realize that means giving up quite a bit of control over anything published as FOSS (but it's a large quantity).

Having said all of that, I think OP is doing exactly the right thing in reconsidering the license. Maybe an OSI-approved FOSS license is not right for this project and a more restrictive license is appropriate, but personally I think that in the face of this new type of use case, most FOSS licenses should clarify and refine attribution requirements. I'd love to see some further guidance from OSI on this.

Edit: for example, it might become recommended practice to put generic, boilerplate, or non-innovative code under permissive FOSS licenses from day one, but leave extremely novel, innovative, or unique code under a more restrictive license (such as one with more stringent attribution requirements) in a separate module for a time, until credit for the innovation is well-established (after which even the innovation can be published under a permissive license). Not a panacea; simply an early thought.

This makes me nostalgic for Trusted Solaris. Nearly identical motivations, but also allowed for runtime context switching (even within running X11 sessions) without a reboot.

It combined Zones, ZFS filesystems, Crossbow network virtualization, a modified X11 server, and an auth framework to glue it all together.

I don't know how widely Trusted Solaris was ever adopted, but I know that I haven't seen it in use in many years. Maybe this particular NixOS strategy will gain more traction.