Even quite underpowered phones can boot in ~1-2 seconds if optimized for that. Not everything in the phone will startup in that amount of time (modem, wifi), but it's possible to start to Linux userspace and display fully interactive UI in that amount of time. Even my e-book reader Linux port boots to UI in ~2s. It really is just bloat and lack of care.
To be honest, I have never seen any phone or computer that could boot in about 2 seconds. 6-7 seconds is the absolute minimum I've ever seen, regardless of hardware or OS.
Software Disenchantment (2018)
351–360 of 504 posts
Re: Software Disenchantment (2018)
#352Earlier quoted context omitted.
My problem with that 8C/32GB machine as opposed to AWS is that that’s literally everything I want my VPC and direct connect.
Sorry, I don't understand the last part of the sentence.
This works great for my personal machines, but not for my company, which wants to do fancy networking things without going over the open internet.
I do fully agree that it’s an order of magnitude cheaper if you know what you are doing though. I’m sure our $3000/month AWS stack would run a lot more efficiently on my $20/month Robot server.
Re: Software Disenchantment (2018)
#353Earlier quoted context omitted.
> I'm thinking why not train a LSTM to take in http requests and generate the http response? Why? With responses generated according to what? Are you really just suggesting using neural networks in the compiler's optimiser? > Then try using a smaller network until something like your registration flow, or a simple content management system was just a bunch of floating point numbers in some matrices saved off to disk.…
I'm suggesting that you take an existing system and build up a corpus of request/response pairs. Then you use the LSTM to build a prediction model so that given a request it will tell you that the current production system will produce the following sql statement and this http response. Once the LSTM's output is indistinguishable from your current production system , for all use cases, then you replace the production…
If you consider yourself a world-leading expert on neural networks and have some secret sauce in mind, by all means, good luck... otherwise it sounds like a fools errand.
Re: Software Disenchantment (2018)
#354For those who don't want to dig, one example was Ember.js, which has a dependency called "glimmer" which makes up ~95% of the code size. The author looked into glimmer and found that it had the entirety of the Encyclopedia of Britannica's "G" section to include a definition of "glimmer" in their help menu.
And that wasn't even the most ridiculous example.
It's shameful that it's gotten this bad; but when you look at what people are expected of in the current climate it makes sense that this would happen.
* Horrendously short deadlines for enterprise CRUD (and the "frameworks" that support it)
* REUSE REUSE REUSE THIS REFUSE (few seem to know how to read source code before installing the dependency)
* "Not paying me enough for that shit"
* "We can't rewrite, we put 20 years into this codebase"
* Even our languages are shit, JS (despite it's usefulness) has undefined behavior as a feature.
* [among many others I'm sure you could think of]
It's toxic, corps incentivize lazy quick work that won't hold up in the long run, but they are too stupid to realize that. Though i blame more so the sycophant that just silently nods and does the work without a sliver of conscience telling them that "this is wrong".Civility has a lesser place in efficiency then what we have now; you can't make a decent product without bashing a few skulls (figuratively ofc)
Lastly, don't be afraid to reinvent the wheel if your wheel is better than mine.
Re: Software Disenchantment (2018)
#355Performance is one thing, but I'm really just struck by how often I run into things that are completely broken or barely working for extended periods of time. As I write this, I've been trying to get my Amazon seller account reactivated for more than a year, because their reactivation process is just... broken. Clicking any of the buttons, including the ones to contact customer support just take you back to the same…
* Measure whether the service you provide is actually working the way your customers expect.
(Not just "did my server send back an http 200 response", not just "did my load balancer send back an http 200", not just "did my UI record that it handled some data", but actually measure: did this thing do what users expect? How many times, when someone tried to get something done with your product, did it work and they got it done?)
* Sanity-check your metrics.
(At a regular cadence, go listen for user feedback, watch them use your product, listen to them, and see whether you are actually measuring the things that are obviously causing pain for your users.)
* Start measuring whether the thing works before you launch the product.
(The first time you say "OK, this is silently failing for some people, and it's going to take me a week to bolt on instrumentation to figure out how bad it is", should be the last time.)
* Keep a ranked list of the things that are working the least well for customers the most often.
(Doesn't have to be perfect, but just the process of having product & business & engineering people looking at the same ranked list of quality problems, and helping them reason about how bad each one is for customers, goes a long way.)
Re: Software Disenchantment (2018)
#356But something crucial is missing from this manifesto. As the author says, the problems don't exist because we can't solve them, but because no one ever takes an interest in solving them. We're all engineers, so why don't we just do some engineering and fix this bullshit? Well, because it wouldn't make any money.
Perplexingly and contradictorily, the profit motive drives both innovation and stasis, both growth and sprawl, and both efficiency and inefficiency. The problem is both technical and social, and probably so will be the solution.
Re: Software Disenchantment (2018)
#357The linked Medium article (when talking about npm) was what I expected, but gives wonderful examples of just how bad it's gotten. For those who don't want to dig, one example was Ember.js, which has a dependency called "glimmer" which makes up ~95% of the code size. The author looked into glimmer and found that it had the entirety of the Encyclopedia of Britannica's "G" section to include a definition of "glimmer" in…
Re: Software Disenchantment (2018)
#358The linked Medium article (when talking about npm) was what I expected, but gives wonderful examples of just how bad it's gotten. For those who don't want to dig, one example was Ember.js, which has a dependency called "glimmer" which makes up ~95% of the code size. The author looked into glimmer and found that it had the entirety of the Encyclopedia of Britannica's "G" section to include a definition of "glimmer" in…
Re: Software Disenchantment (2018)
#359> 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 actually do this for development and it works really well.
Ubuntu Linux VM in VMware Fusion on a Macbook Pro with MacOS.
Power consumption was found to be better than running Linux natively. (I'm guessing something about switching between the two GPUs, but who knows.)
GPU acceleration works fine; the Linux desktop animations, window fading and movement animations etc are just as I'd expect.
Performance seems to be fine generally, and I do care about performance.
(But I don't measure graphics performance, perhaps that's not as good as native. And when doing I/O intensive work, that's on servers.)
Being able to do a four-finger swipe on the trackpad to switch between MacOS desktops and Linux desktops (full screen) is really nice. It feels as if the two OSes are running side by side, rather than one inside another.
I've been doing Linux-in-a-VM for about 6 years, and wouldn't switch back to native on my laptop if I had a choice. The side-by-side illusion is too good.
Before that I ran various Linux desktops (or Linux consoles :-) for about 20 years natively on all my development machines and all my personal laptops, so it's not like don't know what that's like. In general, I notice more graphics driver bugs in the native version...
(The one thing that stands out as buggy is VMware's host-to-guest file sharing is extremely buggy, to the point of corrupting files, even crashing Git. MacOS's own SMB client is also atrocious in numerous ways, to the point of even deleting random files, but does it less often so you don't notice until later what's gone. I've had to work hard to find good workarounds to have reliable files! I mention this as a warning to anyone thinking of trying the same setup.)
Re: Software Disenchantment (2018)
#360The software in nutshell is programmable transistors. Each CPU instruction is in effect just a convenient way to design a specific electronic circuitry. Even a trivial act of printing Hello World takes an astonishing amount of complexity when you take into account all kind of protoicals, APIs, driver codes, kernal code, fonts, rendering, graphics that gets executed in between. If you showed a computer printing Hello World on screen to someone from 1920s who knows how to build electronic circuits and primitive "display", they can estimate the amount of work that would be required to do that. Nothing has changed from 1920s to 2020s in terms of complexity to enable simple Hello World. A relatively simple program will easily exceed 30,000 low level components working together to achieve a goal in an intricate dance. Now think of large code bases with million lines of code... This is why software is hard, software is complex, software is messy and software is magic.