Re: Proof
Now you've done it.
"Hey AI, after you're finished with that, write up a business plan to incorporate a new startup company, and then a sales pitch to flog the lot to whatever big AI company looks ripe for cashing out."
354 publicly visible posts • joined 20 Dec 2013
Netapps isn't all it's cracked up to be either. Or used to be cracked up to, perhaps.
I loved my pre-"C-mode" filers that ran OnTap when it was still called that, before "cDOT" or "Clustered OnTap" or whatever the marketing is these days.
Nowdays Netapps seems more interested in cloud things than their (former?) bread+butter NAS iron, which seems a shame. I'm sometimes a bit surprised they're still selling on-prem metal.
Anyway, that's in the past for me, I'm happy enough with native FreeBSD ZFS fileservers, though I do plan to have a look at FreeCORE and bsdNAS (XigmaNAS was already on the todo list) next time I have storage server kit to redeploy.
Sure, I dealt with quick rails towards the end as well. Most of them were pretty nice, but you can ding up your hands and fingers on those too. :-)
Not really the point, though. AWS's cloud architects may not be touching the metal, but somebody is doing it for them. Not quite "clouds all the way down", eh.
"They politely chuckled at my joke about cage nuts once they got the reference"
I shouldn't let this bug me, but it kinda does. I mean, *somebody* is still installing their servers in racks, and doing the (often OCD) cabling job. Labels/tags, inventory, etc.
Just because AWS folks have (I'm guessing) outsourced it or some similar move, doesn't mean the work happens by magic or telekinesis. Or AI android bots. Though I imagine somebody is working on that....
> we cant trust the large corporations ... to tell us the truth
Apparently, according to TFA, sometimes we can't trust them to tell us anything at all, eh?
"a water service agreement between the municipality and the operator, and these can include provisions that limit the disclosure of this information"
Flip your coin whether you'd rather be lied to or stonewalled behind bureaucracy.
Dunno about "absolutely" but IME it's still pretty true.
I'm a user and syadmin rather than a developer with a commit bit so I don't speak for NetBSD officially, but I believe it's still very portable and runs on many architectures. I follow several of the port-* NetBSD mailing lists, and while some are more active than others, they're still going. E.g. the VAX from your example has threads as recent as July.
That said, I think some of the older ports I used back in the 90's and 00's have fallen off somewhat in terms of active support and updates. E.g. I used to run some of my domains on SPARC (32-bit, e.g. SPARC20 et al) and while maybe not as popular as i386/amd64, it still "felt" (anecdotal) like a first tier port. Today SPARC is tagged tier2, so things like the full suite of pkgs may not be readily available for download, though you can build from pkgsrc, which is also a great way to go, from personal experience.
Similar situations with the NetBSD ports for alpha, sgimips, and macppc, which I also used and remember fondly. I think this is somewhat a natural progression, since most of that gear is decades old by now, and resources for developers to code and test etc. on native hardware might be scarce sometimes. Similarly, as the amount of vintage running gear decreases, so too does the user population. I myself lost the last of my i386 systems in the last couple years due to hw failure, they were running NetBSD at the end. :-)
Btw, if you want to check out the tiers, the tags are listed here:
https://wiki.netbsd.org/tag/tier1port/
https://wiki.netbsd.org/tag/tier2port/
None of this is meant as a criticism of NetBSD -- far from it; merely an observation on the inevitable passage of time. I have nothing but admiration for NetBSD and if I were to ever acquire more 90's era hardware, or just some non-x86 thing that might be interesting, I'd certainly be checking for a NetBSD port that might fit.
I remember those Alpha days -- good times!
Restricted binaries is still true in some cases, e.g. /sbin/ifconfig has some of the execute bits turned off. Along similar lines, /usr/bin/w is moved aside, and /usr/local/bin/w is a script which calls it with "-n", presumably to avoid the delay from DNS lookups for logins from hither and yon. They run 'ypbind' but the query commands (ypcat, ypwhich, ypmatch) aren't available, maybe other things I haven't run into.
SDF isn't my "daily driver" home base, but I still use it from time to time and I'm quite glad it's there. Still have one or two of the old t-shirts in the closet, hanging in there just like SDF and NetBSD. :-)
> it also has one of the most welcoming communities we've encountered in years.
Wholeheartedly agreed. It's common to see the NetBSD devs and veteran users actively participating in the mailing lists, and often as not they're refreshingly candid about shortcomings in NetBSD code or docs etc., while still being very helpful about things to try, and encouraging more involvement. E.g. I've submitted a few bugs (NetBSD calls them "PR") after discussions with folks on mailing lists, which concluded with "yeah, that's a problem, you should report it!" A couple have been fixed as well, making it into 11.0 btw. :-)
People may come to try NetBSD for various reasons, but the community IMO is one of the best reasons to continue with it.
I imagine if "AI" were ever tasked with organizing layoffs (which has probably already happened) the C-suite and their chosen ones will be automatically excluded from the model.
Just as it ever was.
OTOH, it would be interesting to see what the machine comes up with if it were not artificially constrained. We know from history that layoffs often tend to select on criteria like age, tenure, salary size, and similar things which are viewed as being costly to the bottom line. From top of the org chart to bottom, if an unbiased analysis were done, you'd think (big compensation + old) would tend to skew towards the upper management ranks.
My guess is "subject to human review" is doing a lot of heavy lifting in the CEO's comment. You were correct to emphasize it.
That is, they got a human to look at the code at some point. Probably just as it was shipping. It may have been a 1st year marketing intern with no coding chops to speak of, but at least an alleged human reviewed the code, eh?
That figures. E.g. customer size aside, some are enticed/bribed/forced with variations on hostage situation, or bait-and-switch deals, and possibly with desperation as a motivator.
Problem is, at some point "best in class" becomes "we don't suck as much as the others", and eventually even that becomes unbelievable.
Atlassian or Microsoft-Github: when there are no good options....
[reminds self to be grateful for only having been a brief Atlassian user of a couple products, and never an admin responsible]
I imagine github reliability and stability has already been a liability for some folks' operations.
I think it'd be interesting to see if that liability has/will translate into users and customers migrating away from the platform.
In theory, fewer users = lighter load = better reliability, but anybody's guess how that actually plays out.
I also wonder if Microsoft's customers for github are predominantly individuals and small shops, vs. large companies who might be able to roll their own if the service degrades beyond their tolerance.
"IoS [and NX-OS] became like Windows"
Nitpick. Otherwise, yup.
I can remember early IOS (and CatOS?) cli being fairly small and tidy enough that even a primarily Unix person like myself could remember most of the important bits without too much bother. At least for basic switching activities, routing maybe another matter.
Whereas last time I touched NX-OS, circa Nexus 9K family, istr the cli help output scrolling for a page or two. Granted, much more capable (read: more features, at least) gear than Cat5500 and FDDI concentrators and such from the older days, but the additional complexity was sometimes daunting. Dunno what it looks like these days.
The helluvit is, financial analyst types aren't fooled by any of these sorts of shenanigans. One only needs to see a few quarterly reports like this and it becomes familiar territory.
And yet many of them go along for the ride, pushing NASDAQ: AMZN to their clients, glowingly writing about it in their blogs and reports, etc. Because that ride is how they make their money too. Clicks, subscribers, transaction fees, and so on.
I can remember back in the dark ages (pre-dot-com boom and bust) when earnings releases would sometimes have a bit of creative accounting, e.g. trying to paper over a shortfall in one part of the business with another part's excess, still deceptive but usually not outright lying.
Nowdays the big outfits don't bother as much with the subterfuge. Sure, there's the occasional pesky shareholder lawsuit, but there's little to fear from politicians, SEC, etc. as long as suitable donations and tributes are paid.
I found that removing the "open to work" tag/banner/whatever from your linkedin profile helped cut down on some of the headhunter spam. But not all.
I suspect that even deleting the profile altogether won't completely make them go away. There's undoubtedly a lot of cached info still out there, if your CV was ever public for a time. The resume sourcers don't care if yours is actually a good fit, they just want to fill their quota.
At some point maybe I'll age out beyond the range the AI bots and page scrapers consider acceptable, but it hasn't happened yet.
> The problems are HR departments and managers in these firms. There are people willing and able to do the work.
Yes. But not always at the wages offered by those HR departments and managers.
Plus, the (presumably "AI-powered" these days) ATS used by those companies tend to screen out people whose CV's indicate they might be old, expensive, or don't check every arbitrary box on the job post kitchen sink checklist, etc.
It's not quite the same, but I remember a hiring manager a few jobs ago whinging about not having any candidates for a job opening they had sent over to HR.
N.B. hiring manager didn't say "good candidates", they hadn't seen any. The story goes that 2 things had happened:
1) HR had taken the hiring manager's job description, which was reasonably representative of the job role and duties, slathered it with HR boilerplate, dropped some of the manager's requirements while adding some of their own, and lowered the job rank from senior/experienced to mid/junior (presumably to fit salary budgeting line item)
2) HR proceeded to screen candidates based on their fabrication, and consequently had no candidate resumes to forward along to the hiring manager for review
Hiring manager worked out what was going on after reviewing the public job post. I doubt there were real repercussions, unfortunately.
> They can have serious uses but they are illusory toys. They should be treated as such.
Illusory is an excellent term for these things, and I quite agree.
But that's hardly how these softwares are being presented by the AI peddlers, is it. It will change the world, solve all the problems, etc. as long as the owners are allowed to keep shoveling more and more money into it, without regulation or restriction. Therein is the lie, or I suppose "marketing" if you're feeling gracious.
I've experienced the "hallucinations" (i.e. the thing parroting made-up results) like you mention, and followed down a llm rat hole for a while until deciding the effort was futile, etc. So while I'm no expert, I've learned to be skeptical of AI babble just as I would results from a websearch or similar.
Problem is, too many people treat these things like deus ex machina, and the billionaires who promote and peddle the things do nothing to disabuse that. On the contrary, as you also mention, the things usually present their findings with strong confidence, emulated though it may be. To many people it might as well be magic.
> If these responses were from a human being (sitting/standing in front of me) I would be worrying about this human's sanity (and my safety)...
If I got these responses from a human I'd be thinking "liar, only corrected yourself when caught, and then back-peddled with lame barely-believable excuses."
Since you got these responses from a piece of software programmed to pretend to be a person, some of the excuses/explanations might be somewhat plausible. E.g. the bits about the training data not being a "live feed" or whatever it spat out.
But the behavior of the software makes me think the programmers (or the rich oligarch tech bros giving the orders) are trying to lure and deceive users, presumably to prolong "engagement" (i.e. clicks), and cover-up or excuse the flaws in the software.
If "Telegram" is referring to a desktop messaging app, Alpine Linux seems to have v6.8.5 in the community repo, including x86 32-bit on latest release Alpine 3.24
Disclaimer: I'm only using Alpine for small servers, no graphical desktop. But the Alpine Wiki talks about XFCE installation, and screenshots and such aren't hard to find.
I agree on "not for day to day desktop", at least. I had a small ITX VIA 32-bit system with 1GB RAM running Debian (originally installed with 8.5) for a few years.
It was entirely serviceable as a backup network services system for the lab, handling DNS, NTP, DHCP and similar. As a headless server with serial console it was fine, but modern graphical activities were a slog.
It wasn't the most efficient thing to use, e.g. a newer 5th gen NUC is more capable and draws less power, but it was a hobbyist's labor of fun.
> service and sysrc -- don't know them; suspect, gone
service is sort of a shorthand command for listing and controlling rc.d stuff. E.g. instead of '/etc/rc.d/mydaemon restart' it's 'service mydaemon restart'. It also has functions for querying and updating enabled|disabled services, and things like that.
sysrc is a tool for updating rc.conf-style files. Many of us greybeards grew up with BSD manually editing /etc/rc.conf et al, or your favorite echo/sed/awk games. sysrc provides a safe(r) consistent interface for that sort of activity. I was aware of it well before I used it much, but nowdays it's my default method during initial system setup and config procedures.
So yeah, if rc.conf isn't a part of the NextBSD administration and config stuff, it makes sense that service and sysrc would likewise be absent.
> replace FreeBSD's traditional and server-focused userland with the relevant parts of the publicly available Apple code.
I'll be interested to see how this works out, and how far it goes. E.g. I'm thinking about it from a sysadmin perspective and I wonder what becomes of things like rc.conf, service and sysrc, the forthcoming rcd service daemon, etc.
Probably I'm not really the target audience for NextBSD, and that's okay, though I do expect to test drive after they've got something installable. If this project brings anything back to FreeBSD on the desktop (laptop) then so much the better. E.g. it'd be neat to see Gershwin et al as a pkg. [yes, GhostBSD]
Really though, I'd be pretty satisfied if FreeBSD simply more fully embraced something like Xfce, including installer support, for those times when I'm installing something other than the usual servers.
I wish I had a more thoughtful response than "because UEFI kinda sucks". Absent that, I'll parrot our gracious author:
> ... size and complexity of UEFI.
> (I still think UEFI was secretly the revenge Intel wreaked on the PC industry for its crime of choosing AMD's 64-bit extensions and not Intel's.)
To be fair I'm no great fan of legacy BIOS either, and at risk of repeating myself, I admittedly think it's been downhill since OFW fell by the wayside years ago.
From a simply practical operational standpoint, I don't love running into UEFI implementations which seem like differences of opinion among vendors. That seems to have gotten better over years, but I still have to deal with enough old gear that it causes me trouble sometimes.
I'll allow that having (something like?) UEFI as an operable standard, as far as it goes, is better than nothing, and probably better than navigating the mish-mash patchwork quilt of bios-y things, uboot, fdt etc. on ARM these days.
I muddled through Covid well enough, but not Teams. There might be a lesson in that.
Even though my mandated usage of Teams was relatively brief, I still feel dumber for having been exposed to it. I take some small solace in the fact that I was never really proficient with Teams, so hopefully I wasn't seriously damaged by the experience.
My first real job interviews came about because an actual live sysadmin person (not HR, nor even hiring manager) posted the job position on Usenet. Using their actual email address for the contact.
Sent them a copy of my (ascii text) resume by direct email, no Linkedin, Monster, Indeed, blah blah blah. I don't recall that those things even existed back then -- Gopher was barely a thing, and WWW certainly wasn't in common use.
Didn't get that job, but the next interview not long after came by the same path, and that turned into my 1st tech job outside of university.
I've gotten other interviews and jobs since then using Linkedin, PDF resumes and so on. Suffice to say I'm relieved to not need to use A1 for it these days, I'm certain it would be exhausting and demoralizing and probably futile.
> [Red Hat] does not regard _itself_ as a Linux vendor.
Unsurprising in some ways. It may explain some of what they've done since they ended Red Hat Linux. E.g. neglect for some parts of Linux, apathy for others, so Red Hat could take things in other directions which they control.
Perhaps because Red Hat don't consider itself a steward of Linux, they presumably don't value it as much as the "server OSes, cloud provisioning & management tools, virtualisation, storage", at least, not beyond Linux as an underpinning to Red Hat's other products. Makes sense, what with corporate profits and all that.
I do think you've noted a core Red Hat behavior, with "RH went the other way". Red Hat wants to create (or buy?) the New Shiny, different and separate from others. They control it, develop it, declare it the standard, and because they're the 800lb gorilla (even moreso now with IBM) they can inflict their wares on everyone, who can either play along or get shut out. Doesn't matter whether the thing follows The Unix Way, or even The Linux Way, as long as Red Hat controls it.
Shame we don't have access to any (merely) 7-year old DEC hardware to try it, e.g. with modern NetBSD. Even the good solid DS and GS systems are well over 20 years old by now.
Circa 7 years ago RHEL 6 was EOL, 7 was mature and 8 was new. The CentOS rug-pull wasn't far off.
Somewhat cheekily, but in some ways I'd say both parts of the hw & sw equation have been going downhill.
I used it for the last year or so of my tenure at $JOB-2, when Corporate IT finally decided after a couple decades that they were done providing standards-compliant LDAP, and anything except Windows for that matter. This was at a company whose products were largely based on Linux and BSD, mind you.
More than a few Unix/Linux engineers simply packed their things and moved on; I tried OWA from my Linux+Firefox desktop (since I didn't need IT support) and mostly carried on okay with it. I won't go as far as saying it was a good experience, but it was less painful than the full-fat Outlook client on a Windows desktop. OWA wasn't awful as a webmail client, but that's admittedly kind of a low bar.
> the manufacturers generally don't want people loading different software and some of them go to great lengths to prevent us doing that.
All true enough. Among other reasons, it's why OpenWRT and other open source projects (plus the Linux and BSD's in general) often struggle to support kit from the likes of Broadcom, Nvidia, et al. Even long after the vendor has abandoned the gear.
It's not hard to understand why: those companies make money from selling more gear; when customers' last-year's-model is no longer supported, the vendors want you to go buy a new one, not put some Linux or BSD bits on the thing.
I get it, but it's a shame. All the usual points apply: it's often still perfectly serviceable gear, keep some e-waste out of landfills, the open source bits might actually be better than the original vendor's software, etc,
It's not a new idea, I'm certain I've read other comments here saying similar, but I'd like to see some kind of law or at least industry standard which says once a vendor EOL's a product and no longer supports it, they make it possible for someone else to do it. Release the hardware specs and product docs and so on. Wishful thinking, of course.
Yeah, I remember those days. And sometimes the PC mags even came with the software inside the wrapper. It's a fine notion, and was pretty practical on the face of it.
The tricky bit is working out what the modern equivalent for ARM would be. Not only for the MS-DOS or $[game] test case, but also the various PC mags as a widely accepted medium to communicate the de facto standards.
Seems unlikely to happen organically for today's ARM market, as there are already such a plethora of little ARM gadgets, all different in one measure or another, and presumably most of the companies selling them believe they are / should be the new de facto standard.
When in reality, many (most? all?) of them aren't even that standardized amongst itself. I've remarked elsewhere that various rpi models are separate enough that they use different power, cases, and occasionally peripherals (HAT boards and such). To say nothing of requiring different OS images, mostly.
Small wonder that Raspberry Pi are not very compatible with Orange and Banana, nor PINE or ROCK et al.
It's not all gloomy, e.g. supposedly the GPIO pin headers are pretty commonly done, and common I/O ports (HDMI, USB-C etc.) typically operate the same way, presumably mostly due to their own standards rather than the SBC/SOC vendors. But when you can't even buy something as mundane as a case or power supply and hope to have it work out for at least contemporary models of ARM gadgets, it seems like a muddle.
I confess I hadn't heard of SBSA/SBBR until just now. However, I am admittedly only a casual ARM hobbyist, not any sort of platform dev or the like, and my experience with them is limited almost entirely to consumer kit like rpi.
But that's also sort of a notable point: in x86_64/amd64 land, one can generally use the same OS (possibly even the same installation media) for an ITX desktop or SFF PC as for a big multi-core server. And modulo "enterprise" hardware features like BMC and such which typically aren't found on consumer gear, you likely wouldn't be completely lost configuring BIOS/UEFI on the one if you'd ever done it on the other.
Similarly, an ITX/ATX motherboard will fit a desktop case as well as a server chassis, assuming everything follows spec.
Now, maybe it's not fair to equate SOC (rpi et al) with amd64 desktop PC's, and so the server-to-desktop comparison above isn't valid. Is there something in ARM64 circles between commodity kit like rpi and higher-end servers? What api and specs etc. do they typically follow?
Similar story here. I'm not particularly singing the praises of any modern-era hardware vendor, but our Supermicro gear had a better run than our IBM/Lenovo and HPE fleets.
Now, I will give kudos to Lenovo field support; if your contracts and such were in order, they were on the job pretty promptly and generally a good bunch to work with. The RMA operation (e.g. for small parts like disk and DIMM which could be exchanged via shipping) was reasonably efficient too.
You'd think, what with computers being good at maths and arithmetic and such. Though perhaps not as much with the more ... creative ... aspects of accounting. I'm sure the A1's could pick it up and parrot that stuff too, though.
Still, much like the Executive class and HR are typically not among those laid off during headcount cuts, seems like the people enacting budget cuts are often similarly excluded from A1-inspired layoffs.
Seems like once things have deteriorated to the point where a customer and provider are lobbing suits and injunctions and other legal bombs at each other, any hopes for positive support outcomes are probably minimal.
Imagine the poor customer vmware admin and beleaguered tech support engineer trying to have a productive conversation over some misbehaving piece of esxi or whatever in the customer estate, when both have possibly been instructed by their higher-ups to give nothing away and treat the other party as adversarial.
I've no insight into T-Mobile's operations, but if they haven't been exploring options prior to this, even as a JIC contingency, then they're simply not paying attention; it's not like Broadcom haven't been up to this sort of thing before, and any customers have to know something like this is a possibility.