If SaaS/consulting/architectural firms are engaging in price gouging of their customers, that is not an argument to bring the same to the fast food market.
51 karma · joined August 15, 2015
If SaaS/consulting/architectural firms are engaging in price gouging of their customers, that is not an argument to bring the same to the fast food market.
I remember the speaker saying about how they had no idea about how to debug node programs. My personal reaction was that this was a fun little toy, but the idea of JS on the backend was utter madness. Little did I know what a monster it would become.
For the record I still think JS on the backend (or anywhere else) is madness.
Or maybe use: `find ... -print0 | xargs -0 ...`
I guess you're still hoping your filenames don't contain an ASCII NUL, although that's a fairly reasonable assumption for all but the most paranoid use-cases.
I too am required to use a Windows machine for work, which seems to get worse with every release. They even ruined notepad.exe. The bloat is unavoidable. The new laptop I got one year ago that seemed more than enough when new, is now struggling under the bloat. It takes me in excess of 10 minutes to log in, connect VPN, start teams, outlook and putty in a citrix session. Madness!
Linux.
> AI
The slop people are complaining about.
> and enterprise solutions.
Business users are totally fed up of poorly-function Co-Pilot buttons in every UI. The people who sign contracts are not the people forced to digest the cruft.
Place your bets.
There might be some issues with retro fitting the world's existing road vehicle fleet, but that's a deployment detail. :p
I suspect what it will actually boil down to in many cases is having recall enabled by default and an always-listening voice assistant.
Much of the discourse around this topic has described ideal testing and deployment practise. Maybe it's different in Silicon Valley or investment banks, but for the sorts of companies I work for (telco mostly) things are very far from that ideal.
My view of he industry is one of shocking technical ineptitude from all but a minority of very competent people who actually keep things running... Of management who prioritize short term cost reduction over quality at every opportunity, leading to appalling technical debt and demoralized, over-worked staff who rapidly stop giving a damn about quality, because speaking out about quality problems is penalized.
So true, and yet so common.
Don't know how that would look practically (how bright can one really make a polaralized light source that is cost-effective / how expensive is it to create whole windscreens that are polarized / getting it rolled out would be a challenge).
Still it's a very anoying problem and it would be nice to find a decent solution.
I didn't have any training in COBOL, but found it pretty easy to read and understand - at least for the fairly simple business logic in a billing system. I didn#t have to write anything - just do some debugging when it didn't output as expected. Wouldn't want to do anything too mathsy or heavy string processing with it, but it seemed a good fit for the application.
I did some more work for the same company later. A descendent of that software is still running today. At some point between 2000 and the late 20-teens they migrated to Linux, and I think at that point used some sort of COBOL-to-C transliteration software, and the Microfocus compiler was jettisoned. Not sure if the decision was because Microfocus was very expensive (I have heard that, but have no personal experience of it), or just didn't support Linux at that time.
That transliterated code is still running today, but a bit of a nightmare to maintain. If GNU Cobol has been mature enough whenever that migration happened, I suspect it would have been a much better approach than transliteration. Too late for that code base though.
Nope. >:(
Circles.
MicroEmacs -> Pico -> Nano -> Micro