Hacker Newsnew | past | comments | ask | show | jobs | submit | edg5000's commentslogin

What could happen is a reduction in the amount of programs used, with a smaller set of more sophisticated programs doing more work. This maps to what we saw pre-industrial revolution: lots of small family operations doing menial manufacturing work (woodworking, textiles, cooking). This got replaced by large factories. A smaller amount of companies producing the a larger volume of goods. With AI, a smaller group of engineers could handle more local complexity, thus allowing more sophisticated, general purpose software to be created, deleting the sea of small pieces of software we have today.

Will this means many will be jobless? No, they would do other things. They'd be using this software to support society, operating at a high level. Think low-code, but incredibly complex stuff; just not raw code anymore. Instead of making circuit boards out of descrete components, you now slap a few ICs on a board with some supporting passives and the work is then all done in software. Engineers use more high-level components rather then welding and machinijng things from scratch; you buy T-slot profiles and bolts rather than casting and milling steel from billets.

So the job of programmer may disappear simmilar to how we don't have bakers anymore, baking is done in factories, operated by a small staff. Current-day programmers will then increasingly shift to whatever high-level constructs we'll come up with, this high level work will be supported by the base infrastructure that those who still touch raw code will build.


From what I have observed in my team, the opposite is occurring. Everyone is just making their own software because the barriers are so low. There is a lot less sharing and coordination going on, and the bottleneck moved to having the hardware available to run it all, so now we’re spending a lot more money on compute.

Factories benefit from economies of scale that favour centralization.

I think smaller groups handling more complexity is on point. But that's because each group will build their own bespoke factory catered to their exact needs.

I very fully expect a mass proliferation of custom programs rather than standardizing on a common set that groans under the weight of being so general to support all use cases.


This is very interesting. This could allow custom harnesses to be used economically with Opus. Depending on the usage limits, this may be cheaper than their API.

Now I want to see that 2TB query! Such a cliffhanger!

For files I use the open source Material Files, which supports SFTP servers. So I just have a little file server. For calendar, because Google doesn't reliably support background services, it's best to use a calendar app with builtin caldav sync. For carddav, I use a background sync app though (davx). Super lame that this is not built into android, not even into lineage. You'd think someone would implement native caldav/carddav sync? Maybe this is my calling haha.

I'm telling that someone who comes up with a decent file sync setup between iPhone, Android and Linux/Windows without charging a monthly fee will make some good money on one-time buy fees alone. Dropbox etc can do things like these but I'm not interested in paying monthly fees for using my own storage across devices.

For my desktop systems I do a nighly rsync to a central onsite server, which does nighly encrypted ZFS send to an offsite archive. I suppose a script could trigger on file change using Linux file watch features (exposed via CLI and C headers). What I'm not sure about is wether two way sync with rsync is possible. This could run as a simple daemonized bash script. On error the script would just retry. Rsync would have to handle conflicts, it probably has features for it. Paste this comment into a coding CLI and boom, you have your solution :). Does need rooted Android for running shell scripts on boot. But a good coding CLI can log into your phone and set everything up.

Have you tried KDEConnect?

Every day, its great. But it is more suitable for adhoc sharing, not keeping pairs of folders in sync like Syncthing does.

Banking and govt. on a cheap, locked Android. The rest (mail, calling?, SMS, web, on an unlocked Android). You'd need two SIMs, one for the banking/govt google play stuff, and one for the regular phone. My bank does support a physical reader device though. That may eliminate the main Google Play dependency. Open Android will still exists right? But it won't have the Play Store and Services. You could also download the APK on the official phone, then pull the APK off it and install that on the open phone. Won't work if the app requires play integrity, but I think there are alternatives for that. Pretty lame that this is needed, but I'm used to this crap anyway.

> The only thing that bothers me more are the, “sign-in with Google”, prompts on 90% of websites now This drove me really, really mad last winter. How did they even achieve this? My policy is no US vendors. Period. Not for work stuff at least; not for things I depend on. What a mess.

Which types of tasks, in your experience, show negligable improvement when using larger models? And for what types of tasks do you feel even the best models deliver mediocre results?

This is very cool

Very interesting stuff

Well articulated!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: