Software Disenchantment (2018)
241–250 of 504 posts
Re: Software Disenchantment (2018)
#242> Linux kills random processes by design. And yet it’s the most popular server-side OS There's no reference for this in the article, and it caught my attention - anyone have any idea what the author is talking about here? Never heard of this before
Re: Software Disenchantment (2018)
#243Programming is now a bureaucracy. [1] "In any bureaucracy, the people devoted to the benefit of the bureaucracy itself always get in control and those dedicated to the goals the bureaucracy is supposed to accomplish have less and less influence, and sometimes are eliminated entirely" [1] https://en.wikipedia.org/wiki/Jerry_Pournelle#Pournelle%27s_...
For instance, I started noticing that a lot of the code I've written or worked with in many projects have a particular flavor to it. Pieces that take some data, repackage it, and pass it on to different code that does essentially the same - all arranged in a structure that's supposed to reflect some shared, abstract understanding of the problem. I've started to call this type of code "bureaucracy", and I see it as something to be kept in check.
Re: Software Disenchantment (2018)
#244Excerpt: "An Android system with no apps takes up almost 6 GB. Just think for a second about how obscenely HUGE that number is. What’s in there, HD movies? I guess it’s basically code: kernel, drivers. Some string and resources too, sure, but those can’t be big. So, how many drivers do you need for a phone? Windows 95 was 30MB. Today we have web pages heavier than that! Windows 10 is 4GB, which is 133 times as big. B…
My favorite was "Google’s keyboard app routinely eats 150 MB. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95? "
...maybe?
I don't know if that's 150 MB' worth of data... but it's certainly a lot.
Re: Software Disenchantment (2018)
#245> Linux kills random processes by design. And yet it’s the most popular server-side OS There's no reference for this in the article, and it caught my attention - anyone have any idea what the author is talking about here? Never heard of this before
Re: Software Disenchantment (2018)
#246> Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? I think the analogy here is backwards. The better question is "how much would you prioritize a car that used only 0.05 liters per 100km over one that used 0.5? What about one that used only 0.005L?". I'd say that at that point, other factors like comfort, performance, base price, etc. become (relatively) much more important. If bas…
I respectfully disagree -- something that is 10 times more efficient costs 10 times less energy (theoretically). When the end user suffers a server outage due to load, when they run out of battery ten times quicker, all of these things matter. When you have to pay for ten servers to run your product instead of one, this cost gets passed on to the end user. I was forced to use a monitor at 30 fps for a few days due to…
I do that for most of my hobbyist Linux dev work. It's fine. It can do 4k and everything. It's surely not optimal but it's better than managing dual boot.
Re: Software Disenchantment (2018)
#247Earlier quoted context omitted.
Ok but why ? And what can we do to improve things? Promote maintenance, but I think one of the issues is that you can show something new, it's much more difficult to show that something could have changed (failure, difficulty to grow), but didn't.
To the extent it's in your power as a developer and a team member, don't tolerate low-performance code from yourself or your co-workers. In my experience, a lot of performance problems boil down to really stupid problems, like simple code using the wrong data structure out of convenience (e.g. linked lists instead of arrays for lots of randomly-accessed data), or structured in a bad way (e.g. allocating a lot of smal…
But I have a different experience (probably because we work in different areas):
Most the performance problems of the products I ever worked were purely systemic.
They boiled down to technologies and architectures having been chosen for "organizational" rather than technological reasons.
And "organizational" is in quotes because sometimes it was just blackmail: I worked with two developers who quit in protest after the prototype they wrote in Scala was deemed not good enough and dropped for... being too slow, ironically.
Re: Software Disenchantment (2018)
#248One thing nobody seems to mention is the environmental cost of inefficient software. All those wasted CPU cycles consume electricity. A single laptop or phone on it's own is insignificant, but there are billions of them. Combine that with the energy wasted shovelling unnecessary crap around the internet, and it adds up to a big CO2 problem that nobody talks about.
It's much worse than that: what is the environmental cost of buying a new phone because Slack runs too slowly on your old one? The things I'm doing on my phone today are not fundamentally different than what I was doing ten years ago. And yet, I had to buy a new phone.
Re: Software Disenchantment (2018)
#249http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...
Re: Software Disenchantment (2018)
#250As a dinosaur who has been programming for >30 years, it shocks me how bloated many modern programs are. The installers for my own products are around 20MB and most of that is Qt libraries. But 100s of MB seems to be standard now. The Airbnb app on my iPhone is 210 MB. I understand that if you are shipping a 3d game with maps, textures, sound etc, but not for a mobile phone app.
That is, you can still write small and light software. It takes the same amount of time as it always did, not much changed.
The troubling part is that the proliferation of bloated software is steadily establishing a new status quo - the software is now _expected_ to be big and heavy in order to be proper. Doubly so for the enterprise-y software. Bloat is becoming a sign of maturity and robustness.