ninefathom

This was precisely my first thought upon reading. "Ah, yes - the attack that was PoC'ed against commissaries operated by the US armed forces a bit over a month ago."

There are a few of us around who still make them. I do film photography and have my own darkroom already for that purpose. Adding holography on top of that is a relatively minor lift, and every once in a while the urge strikes and I'll get the equipment out.

The main challenge is that there are, to my knowledge, only two remaining manufacturers of the plates - in France, and in Russia.

While I love this idea generally, the scope of the use of generative AI for artwork is too vague for my comfort.

The README.md mentions that "no art is AI-generated, though some has been retouched with AI." Superficially, that sounds mild. Some of the other closely-related projects, however, use different verbiage, or none at all.

For those of us with ethical concerns around generative AI application to artwork, much more detail may be needed before we could decide if this was appropriate for us.

The BBC did this in their 2012 documentary mini-series "How to Grow a Planet" with Iain Stewart. It was a lovely series; I highly recommend it.

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