Ask HN: Anyone using proprietary Unix at work?
I was born in the late 90s so by the time I got involved in technology, my introduction to Unix and Unix-flavored systems was limited to Linux and MacOS. However, I've read about the history of Unix at Bell Labs, the BSD systems derived from research Unix, and the eventual commercial releases of Unix System V from AT&T themselves. I also see that HP-UX, AIX, and Solaris are apparently still maintained and get releases, which suggests that they are still being used in production in some places.
I'm curious if anyone here currently works (or has very recently worked) somewhere where proprietary Unix is still used for production. If so, can you tell me what they're used for and why those deployments haven't been moved to an appropriate Linux distribution?
Not suggesting Linux is necessarily better for all use cases, just wondering what keeps these small number of entities clinging to closed-source Unix with presumably pricey license costs.
220 comments
[ 5.1 ms ] story [ 239 ms ] threadhttps://github.com/apple/darwin-xnu
I'll bet this isn't even the source code Apple uses, but rather they have a private fork with extra patches (similar to how Microsoft publishes OSS VS Code, but then uses their own proprietary version for releases).
If I run windows with apache web server, is windows now open source?
rMS is a zealot, but it doesn't mean he's wrong...
However, it involved finding some random blog post on how to do it, and then even once I got it up and running there were some issues like the fans being pegged at 100%. Still, it was mostly functional.
[1] http://www.puredarwin.org/
[2] https://github.com/puredarwin
[0] https://www.youtube.com/watch?v=-zRN7XLCRhc
"Coming of Age" and the "Don't Anthropomorphize Larry Ellison" talk are especially great.
This used to run on a Compaq Proliant server (huge noisy Intel 486 tower) until the end of the millennium or so, then was converted into a VM. First on VMware, then on Hyper-V, where it has been running comfortably on various hardware (Intel Dell PowerEdge, AMD SuperServer) since.
Access is the biggest issue, as the OS only supports telnet, and serial access. So ever since this has been converted to a VM, it runs on a dedicated VLAN (666, just to make sure nobody ever misunderstands the true evil underneath...), with an AD-authenticating-HTTPS-to-Telnet bridge (coded up in Visual Basic.NET using some long-long-deprecated libraries) connecting it to the outside world.
That VB.NET kludge was recently upgraded to .NET 6, in order to get TLS 1.2 support. This was surprisingly uneventful, and I'm pretty sure this abomination gets to live another decade or so.
Ah, yes, a career in IT... Always on the forefront of cutting-edge tech...
(Later edit to, like, actually answer the question: licensing costs are nonexistent: SCO is gone anyway, and we don't require any support/updates. Migrating to Linux might be an option, but is most likely going to be hugely painful, and the existing VM scenario Just Works for everyone involved. Security and such is not a real issue: only a handful of internal users have highly-restricted access via a proxy)
The plan is definitely to retire the system Real Soon Now, but with the subjects of the underlying data springing new generations with new lawyers, ensuring some kind of Y2K38 compliance might be wise...
It should buy you another 100 years.
OpenSSH works on it. This page has links to precompiled packages:
https://scosales.com/knowledge-base/how-to-install-ssh-for-s...
links:
ftp://ftp2.sco.com/pub/skunkware/osr5/vols/openssh-3.4p1-VOLS.tar
ftp://ftp2.sco.com/pub/skunkware/osr5/vols/prngd-0.9.23-VOLS.tar
ftp://ftp2.sco.com/pub/skunkware/osr5/vols/zlib-1.1.4-VOLS.tar
Probably better to grab the sources and compile them yourself if you can, though.
> Migrating to Linux might be an option, but is most likely going to be hugely painful.
Probably. At least it sounds like you only have a few users for it, so getting them to adapt to a change of software might be easier.
On "ancient", the ciphers and kex algos used by the OSr5 sshd above were deprecated like 4 years ago. I'd like to think that among the select group of probably-not-technical people that have access, it's not exactly the same bar of technical ability to inspect the contents of a plaintext connection as that to inspect the contents of an encrypted connection that uses ciphers and kex algos deprecated a few years ago.
I run into this issue frequently. Usually its a "client soft disabled, alter config", but sometimes... Just sometimes its "spin up an old VM to use its ssh client".
My first job in high school was at a company with the entire business running on SCO Unix. I want to say OpenServer 3, maybe? It was essentially a terminal server with dozens of Wyse 60 terminals attached.
Anyway, as a Linux enthusiast I promptly setup a RedHat 7 install on some old hardware they had lying around. IIRC correctly it was a low-end Pentium but it could handle a PCI 100mbit ethernet card just fine.
Anyway, the goal was to get data to/from the SCO system to something with a TCP/IP stack (RedHat machine) so it could go somewhere - samba shares on the rapidly growing ethernet network, maybe even the internet!
We ended up using UUCP over serial, scripting, and cron jobs to push/pull from directories on each side. The RedHat machine was promptly connected to a 56k modem to do dial on demand and IP masquerading for the ethernet network and uploads of specifically formatted files from the SCO system via FTP to vendors and partners.
Fun times!
Usually with systems of this vintage, "just dump all the data to Excel or PDF and get it over with" is a good option, but in this case both the volume (with the requirement to run queries on it) and the limited options available for export (the system can only print predefined reports, and they don't contain everything required for filtering) prohibit that.
So, next stop would usually be "reverse engineer the application data format and convert it", but the unholy collection of binary files used by the accounting software here has defied analysis: it's not Btrieve or MS-ISAM (popular semi-database formats for COBOL and BASIC apps of the time), and decompiling the binaries only yielded some generated-by-another-set-of-tools braindamage that didn't clarify anything either.
The choice then became spending huge amounts of money, or wallpapering over the tirefire and keeping it running. Unsurprisingly, the outcome was the latter, which is perfectly OK in this case, as the system is not exactly load-bearing, and actually sort of fun to maintain.
From the highly obsolete format, to a stepping stone in-between which can be converted to a modern format.
Apache Guacamole supports AD auth and (surprisingly) telnet.
Good times
Correction: It has been pointed out to me that I'm currently using macOS which, Darwin non-withstanding, is technically a proprietary UNIX.
Both were excellent systems to work on in dev and prod.
Later on in eh, 2015 or so I worked at a company providing backup software that was tested and worked with every niche unix hardware under the sun. Usually to support large legacy industrial companies, think defense, materials, etc. who still used the hardware.
Banks will also use these things mostly for legacy reasons. The software got written once and has been working and validated for decades, no reason to rewrite it for a different OS just because.
Price is usually not a major factor when compared to the size of the business and number of employees.
When I worked for $(LargeDefenseContractor) we used Solaris for a defense system we were developing. Over time the older units (based on older hardware) would be passed down to the national guard. I would not be surprised if Solaris was still being used in obscure places in the military.
Solaris 7 was a pretty awesome OS as I recall, but pretty soon Intel and AMD started supporting linux as a workable OS option for their server chips. Then linux on the cloud took off and the rest is history.
What am I missing?
One of my college courses ages ago was about working with MPI which we got to run on the hpc cluster.
The last time I needed to run N copies of something I asked kubernetes to do it. The time before that, I asked $cloud_vendor for N identical VMs with the same cloud-init script.
Supposedly Google's in-house stuff that kubernetes and map-reduce (the product, not the concept) are public versions of, is all about running stuff well on huge groups of machines.
For example, large banks need to securely, reliably, and very efficiently process an unfathomable amount of transactions[1]. In this case, kubernetes would be a giant waste of resources and complexity. The former one hampers throughput, the latter one means security and reliability suffer.
For people not familiar with it (me included, actually), it can be mind-boggling what throughput is achieved, and what mechanisms for reliability are in place. Not just in software, in actual hardware; this goes way beyond ECC memory.
[1] Transactions in the bank sense, not in the computer sense, because I don't want to confuse matters more. In the mainframe world for example, there is a difference between "batch processing" and "online transaction processing", but both could be applied to bank transactions. Note that I'm not advocating for the mainframe world here.
[1] https://gnqs.sourceforge.net/docs/papers/mnqs_papers/origina...
[2] https://www.parsec.com/wwwDocuments/ClusterLoadBalancing.pdf
I’m pretty certain most if not all are still running.
I can't say bad things about the whole Sun/Solaris combo though. It's rock solid and requires practically no maintenance whatsoever.
Also, since it's completely off the internet, it's not like it could be compromised in any way.
We also apparently still have some AIX, but I'm not sure what it supports. AIX is still somewhat popular in financial services; probably others as well.
I know of a couple large HP/UX shops left.
That’s an understatement!
Earlier this year I helped our final Solaris SPARC customer move over to X86/Linux. Every year for the last 5+ years they’ve asked us to extend support for just one more year; they were almost done with the migration! In the end, we had to compile them a few pieces of software with weird configurations because they took the standard AWS Linux and, well, I have no idea what on earth they did to it.
Previous to that (late 90's, early 2000's) it was mainly Solaris. One place was fairly heterogeneous, and had Solaris, HP-UX, Digital Unix (aka OSF/1, Tru64), and a couple others.
https://www.usa.philips.com/healthcare/solutions/radiation-o...
Last I heard they were desperately trying to get it on Linux. Why it isn't is because its a huge legacy application with some very horrible hacks specific to the OS.
There’s a bunch of enterprisey technology that is not yet dead, but dying very slowly.
Another similar client is using Solaris (Sparc) for an analogous application; they are using it since 1996, I think because Sun (Oracle) always provided an easy migration path, so the applications didn't need to be ported.
As in most medium/big enterprises, in both cases the hardware/software price is not the main decision driver, but (IMO) it is the support/SLA, compliance checklists, and overall risk management.
BTW, in these cases Linux is also used for more "internet oriented" applications.
HANA is already Linux on POWER so it will be nice not to have the AIX/SUSE split once we fully migrate over.
We tend to run pretty up to date config wise so it's helped quite a bit while planning upgrades. Only AIX 7.3 and SLES 15 SP3. Already moved from P7 => P8 => P9.
There was a common set of cshell based tools used between those two environments, among other 90s style Unix tools, like software written againt the SunOS Open Look widgets, and tools written in Tcl/Tk.
I wonder if those machines are still in use!
I worked at an ISP in 2007 which was running mostly on Sun hardware and Solaris. This was because of huge discounts provided by Sun. Most devs ran Linux on their workstations. In 2014 I got to work with some guy whose previous project had been at that ISP, who was at that point desperately trying to move off Solaris because they had to start paying list price for the OS and it was much too expensive.
They released a major update in 2020 that allowed you to move windows around the screen. It was groundbreaking.
But let me tell you, this system was absolutely terrible. All the machines were full x86 desktops with no hard drive, they netbooted from the manager's computer. Why not a thin client? A mystery.
The system stored a local cache of the database, which is only superficially useful. The cache is always several days, weeks, or months out of date, depending on what data you need. Most functions require querying the database hosted at corporate HQ in Cleveland. That link is up about 90% of the time, and when it's down, every store in the country is crippled.
It crashed frequently and is fundamentally incapable of concurrent access: if an order is open on the mixing station, you cannot access that order to bill the customer, and you can't access their account at all. Frequently, the system loses track of which records are open, requiring the manager manually override the DB lock just to bill an order.
If a store has been operating for more than a couple of years, the DB gets bloated or fragmented or something, and the entire system slows to a crawl. It takes minutes to open an order.
Which is all to say it's a bad system that cannot support their current scale of business.
It just seems that the actual software running on the OS, with the text UI, seems to be profoundly terrible in your case.
The ancient software also wasn't bad. After a few months learning the hotkeys and menu structure, the speed with which you can enter and process data was absolutely incredible. It had problems, but usually minor and patched in a reasonable time for corporate IT.
The real problem was their database management. I don't have any information, so I'm assuming here, but my impression is that they're using some positively ancient database software. Doing a backup of the local cache took multiple days, though it didn't lock the DB. Requests to HQ were incredibly slow, about 30 seconds to pull an account record. Larger queries like neighboring store inventory took a minute or two. Running a report on local inventory would regularly take tens of minutes, and it only had to read the local cache.
The database was a few tens of GB on disk. Granted, I don't know much about databases, but if running something like "SELECT * FROM inventory WHERE sales < 100 ORDER BY lastSaleDate" on a 30gb database takes 15 minutes, something is wrong.
There were a lot of problems we ran into on a daily basis, and almost all of them related to database functions. Particularly when a record failed to unlock, sometimes we'd have to reboot the local server, which caused all terminals in the store to reboot. That usually took a good 15 minutes.
Personally, I rather enjoyed not having Windows at work. For the most part, everything Just Works, and given the hardware, it ran ten times faster than windows would have.
My current job is a Windows development shop, and I don't have enough curses to describe the pure rage I feel every time windows does something stupid (which is approximately every three hours).
My guess is that they bought whatever database software was popular in the early 90s and never changed.
I do know they've been slowly changing the schema over the years, increasing the number of digits in the account number, adding email fields, that kind of thing. But I doubt there's been any major upgrades.
Thinking about it now, it had to have read out the entire database multiple times.
Oh yeah, these reports weren't processed on the server, either. The network link on the terminal I used would be pegged at the max rate the server could read from the disk. I never really figured out what that's about.
I guess it's trying to stream large chunks of the DB to the terminal and running the query locally? No clue.
The vendor went into a cycle of refunding and re-billing my store for that part every few months for years.
Fortunately both our books came out even in the end, but Jesus what a stupid thing to happen.
This is half of the reason everyone who worked at my store walked out on the same day. The other half is that the only people who worked there were me and the manager, and it had been that way for six months.
My advice is to avoid SW these days and go to Lowe's. SW is contractually obligated to ensure that Lowe's always has inventory. But do spend a little extra money for their mid-teir product. The cheapest stuff is trash and you will regret it.