> Among the remaining mysteries, Yusef-Zadeh is particularly puzzled by how structured the filaments appear. Filaments within clusters are separated from one another at perfectly equal distances — about the distance from Earth to the sun.
Sounds like the wake of shipping lanes, the ships even follow regulations to stay a safe distance away from one another, though they really should do something about those older engines that mess up the landscape for everyone with the wakes. If that's not a sci-fi story yet, it probably should be!
A long time ago I worked as the infrastructure & systems manager of an biostatistical institution at a medical university. The institution had a large staff of highly qualified professors and researchers and others, doing cutting edge work on huge datasets, even by today's standards. It was a really well funded research operation.
One day the phone starting ringing off the hook, the mail blew up and I had a large group of people outside my office (no open work space there!) being very upset all of the sudden. It seemed that almost all of them were relying on this quirky internal service for some input of sorts to what they were coding on/with, and all the computations and calculations and modelling broke without it. And apparently, it had broken. So ofc I start looking into it.
All I got was an IP address, and my system lists and IP registers showed nothing. I went on to look in an old patch panel registry, and found a reference that might be something to look into regarding where it physically might be located. But ofc the patch panel wasn't in use anymore, but I knew they sort of moved it 1:1 to a new panel in the far corner of a basement. Got a new lead on where the patch terminated, and went there only to find an empty room. A lone network cable ran from the connection on the wall, through a hole in the back wall to the next room. The other room had no marking, and my key pass didn't work. I called the maintenance guy who came running, and his keys didn't work either. So we took the decision to simply remove the lock by force.
Once inside, I come upon a very strange sight. Again an empty room, with only a very, VERY dusty desk and chair, with an ancient Unix machine and monitor. No one had touched that thing in many, MANY moons. It was disgusting. Someone had set it up to do its work, and then left the building, without notice or documentation, and it had been forgotten. It was a very Tron: Legacy kind of moment. I had a look at it and it said that the raid was downgraded, but still working but somehow halted the machine. I took a chance and rebooted it and after a while it came back online. All the researchers were happy again! I eventually took the liberty to move all the source code off the machine and got help from a co-worker to set it up in a new Linux environment. It worked almost out of the box, my co-worker made some minor fixes to make it compile. For all that I know, it's still running.
This is a old war story that I never will forget, very fun to talk about :)
My father (67, retired) has a couple of friends his age with long time, small businesses in the IT industry. One has been making some sort of map software for a very small niche in the marine industry, another has been making software for bee keepers or something similar. A third in image scanning software. They have been doing well since the late 80s, and still could be. They chose to go out of business and enjoy retired life instead.
I suspect that, although there is a market for the products, noone is interested in taking on the software they worked on.
> I suspect that, although there is a market for the products, noone is interested in taking on the software they worked on.
It may be extremely difficult to do that, for at least a few reasons.
In some cases, the tech is going to be very niche/old, and it will be difficult for people to get up to speed on it.
The business is likely built on a lot of personal contacts, and not all will want to switch to some 'newcomer'.
Many of these smaller business reliant on niche software will go out of business themselves, or be acquired by larger companies that will replace the niche software and process with something else.
The current customers may not actually want anything other than regular updates while paying minimal support/maintenance contracts. Someone established can live off that, but someone new will have to spend a lot of time learning, and the income may not be sufficient to justify all the learning.
I worked on a project in 2018 where some of the (small) company was still running on a combination of foxpro/db2, with a bunch of custom code by an indie/solo vendor who had 'retired' probably 5 years earlier. He'd 'sold' the company to another individual who ... kept it going, but couldn't easily deal with new needs (new reports, etc). Another vendor did an upgrade on the hosting server, and nothing worked after that. The upgrade was a base NT upgrade, and there wasn't any easy way to 'go back' quickly. Things ran off an RDP session to a laptop in Canada running some weird trial emulation tool under windows 7 (this was how it was translated to me from various parties).
Well, if I may, there is something that doesn't sound (to me) "rational".
I have seen quite a few of these cases where a larger company buys the old one (essentially to get a list of their current customers) and then terminates the product replacing it with some crappy new stuff that usually completely fails to work, but in this case the soon-to-retire programmer at least gets some (little) money (and knowledge is lost forever).
But if the one man company is going to shut down because the programmer is going to retire, the acquisition cost for a young, willing programmer is 0.
This hypothetical young programmer could - I believe - invest some time to understand not so much the actual codebase, but rather the workflow of the program and re-write it along that same workflow in a new language/platform/whatever.
I am pretty sure that those niche users would be ready to pay a fair amount of money to have something modern/updated that actually works and works like the old one.
What I have seen often is that the new program, for no real reason, has been written by someone that most probably is much more brilliant at programming but that knows nothing about how the program is actually used, has no idea about how to deal with some "edge" cases (that already surely happened in the tens of years of life of the old software), etc., in some ways it is like all the experience accumulated over the years is suddenly lost and the new program repeats the same (or worse) mistakes/issues that already happened (and that were already solved).
Maybe the problem is that there is not an easy way to tell to the world "I am going to retire, any taker?"
> This hypothetical young programmer could - I believe - invest some time to understand not so much the actual codebase, but rather the workflow of the program and re-write it along that same workflow in a new language/platform/whatever.
> I am pretty sure that those niche users would be ready to pay a fair amount of money to have something modern/updated that actually works and works like the old one.
I don't know. My experience is, for many smaller niche things, they're entrenched in orgs and used The One Way, and any deviation - change a button label, add a menu, etc - will result in a lot of complaints from existing users. They'll have to 'retrain', etc.
No doubt some people will appreciate and welcome 'new/modern' stuff, but many won't. And figuring that out ahead of time is... time. and effort. And along with that, there's usually heaps of institutional/domain knowledge that just can't be replaced without... time in the trenches.
It's not that it's not possible, it's just not typically 'worth it' for most people. ROI is too low compared to other options.
> I don't know. My experience is, for many smaller niche things, they're entrenched in orgs and used The One Way, and any deviation - change a button label, add a menu, etc - will result in a lot of complaints from existing users. They'll have to 'retrain', etc.
People hate this just as much in almost any software (or, most any UI, physical or virtual, for that matter), they just often don't have a way to push back.
You wouldn't know it based on current trends, but consistency and predictability are king in user interfaces, as far as actual usability goes. So much so that high levels of severe bugginess can be preferable than less-severe and common bugginess, if the former is consistent and predictable ("if I press this button then that one, the application will crash or glitch, every single time, no matter what state the program is in—so, I won't do that") and the latter isn't ("about once a day this button takes me to the wrong screen, and the behavior seems random"). If your users are your top priority, changes will occur gradually, and only with excellent motivation. Grand re-designs are among the most user-hostile things you can do (despite their popularity).
[EDIT] to be clear, they don't have a way to push back in the modern age of rolling updates and old versions being infeasible to obtain at all, possibly broken even if you can, and, most likely, full of known vulnerabilities that will never be patched. In the old days of desktop software that you actually purchased, and that operated just fine entirely offline, the way to push back was not to upgrade, and it was common.
Yes, that young, entrepreneurial programmer can be found, but won’t have the domain knowledge. Look at the examples above. You can’t sell Marine mapping software without knowing something about marine navigation. You can’t sell beekeeping software without understanding beekeeping. Plus you need the general business operation skills. Finding a programmer who knows beekeeping and wants to take on a low growth business is not as easy as finding a programmer on Upwork.
Yep. There may be 'takers', but will the existing customers want to work with them? So many solo/indie niche packages are built on the relationships, and replacing those - and the trust around them - is hard.
A client told me about someone they knew who did ballroom dancing software - it kept track of competitions, standings, etc. And... it seemed like decent money, looking at the pricing, and the size of the market. But the market didn't seem big enough for multiple players, and everyone trusted/knew/used the one main player. If/when he goes (or perhaps already has), I'm sure people will find another way to manage their stuff, but before then... who's going to come in to a market like that? How do you 'beat' the incumbent? Lower price? Who would switch? How do you convince people to switch to something unknown, potentially losing years of data, having new training costs, to ... save a couple hundred bucks maybe?
I'm sure there's hundreds of these sorts of services out there that are surviving, but don't have a huge market for competition, because the barriers to entry are too high relative to the return.
Yes, but I was talking more about "passing on" the knowledge/experience (as opposed to losing it and start anew).
Regarding your "The One Way", sometimes that one way is actually the one that works better, as it was developed and fine tuned over the years by a dedicated programmer that had constant feedback by users.
Probably that ballroom dancing software had a way to input (or present/output) data in a form that makes sense to the users.
When suddenly comes the new (otherwise brilliant) programmer that - knowing nothing on the specific field - invents his/her own way to input data or render it that the users find awkward or slower or less intuitive or whatever, with the new program that cannot import old data (or imports partially), that cannot use the same B&W printer because the output is highlighted with colours and not with bolding/underlining, etc..
No surprise that the users of the old software (if it is still working) won't jump on the new bandwagon.
I am using both a dedicated 35mm film scanner (not flatbed) and a DSLR with macro for repro, the latter for medium format film.
The outcome quality of both processes is identical and great quality, but the DSLR repro way is a little bit more cumbersome. It takes me longer to get a really good result with a lightbox than with the dedicated film scanner. Not by long, but it adds up if I have a couple of 120 film to repro.
I shoot repro with a Nikon D700 in RAW using a 105mm macro lens on a regular stand, with a bubble calibrator. The lightbox is a small cardboard box spray painted in black, with flippable/removable cutouts to fit 6x4,5 up to 6x7. I use an old discarded iPad mini, setup with a white image on max brightness as backlight.
Using Capture One (my preference of editing suite), I connect my camera with a USB cable and import directly into the editing suite. No need for importing of a CF/SD card. Smooth process.
> The harder part is now getting a computer that will take the firewire (you may have an old laptop -- macs had them until like 08 -- or get a firewire-to-usb2.0 cable or thunderbolt to firewire adapter on amazon)
Modern computers with thunderbolt will take a converted fw stream without any problem. I am using several old fw400 sound interfaces with a string of adapters without any problems, on both mac and pc. The mac laptop has tb built in, for my workstation pc (Windows 10) I bought a PCI Express io adapter for 30 euro. Works perfectly.
It's crazy how average pay differs from even expensive, technology and knowledge heavy parts of Europe. Where I live, Stockholm Sweden, this would be a very well paid person. Even more so for families, considering it's one income and not two for the household.
In 99% of the US by area, $170k would be a very good salary for a software engineer too.
Silicon Valley is a statistical outlier compared to the US as a whole for salaries and for cost-of-living.
Most of the software engineers in the US don’t work in a place with $170k salaries and $1m+ homes. For most of the US, salaries are 1/2 of that and homes are 1/4 of that.
That's a large reason of why I've stayed in the Phoenix area, though I think about leaving every single summer. The engineering pay is about 2/3 of SF area, give or take, but cost of houses are around 1/4 or so. It's rough thinking of a lateral move in salary, or not enough of a boost to overcome cost of living differences.
Of course housing costs have gone up significantly relative to pay in the past decade, so who knows.
I remember slightly earlier on in my career as an intermediate level engineer earning $70k living in an area (not in US) where the median house price is $1m+
