How often is the UI spec modified in practice compared to the frequency of UI changes? I wonder if this scheme actually reduces app update frequencies much. I can imagine that UI improvements often would require spec changes. Imagine adding colors to the map POI's, etc.
I've read several articles about this SuperNova trojan, including a couple that included decompilations, but none included what ought to be two key details:
1. Was this GIF-fetching endpoint likely exposed publicly by most customers' SolarWinds deployments?
2. Public or not, was there any auth in front of this endpoint when deployed?
My presumption is that some (most?) customers deployed the SolarWinds admin console publicly (with its own auth in front) and that this particular GIF-fetcher endpoint, being deemed trivial, was not protected by the console's auth scheme. Thus, those who knew about the trojan just had to scan the known IP ranges of SolarWinds customers until they found the exposed admin console, and then remote code execution was easy from there.
If this endpoint was protected by the same auth scheme as the admin console, then this trojan becomes more of a privilege escalation attack. Its existence would increase the value of obtaining the creds of a SolrWinds user, but (presuming SSO integration) those creds would get the attackers lots of other access given the sorts of IT people who use SolarWinds.
If the endpoint was not fronted by any auth scheme but the admin console was not exposed externally, then the benefit would be that attackers who gained access to a SolarWinds customer's employee-facing network (what's the name for the network segments accessible to anyone who plugs in a laptop in a cubicle?) could "ride" this trojan to gain access to a more privileged part of the network.
I'm not an infosec guy. Do these arguments make sense?
So, the user graph will be bifurcated, with US users isolated from those in the rest of the world? If so, I don't see how the US-only TikTok remains popular for much longer.
I'm surprised a manufacturer of such engineering machines hasn't differentiated itself by offering a SLA on driver (and general software) availability for future operating system versions. It would be reasonable to require users to pay a subscription fee for extended support. I'd think the resale value of machines with drivers still available would be much higher than for those without and that this eventually would allow the manufacturer to charge a premium price for the machine at initial sale.
I own a Fujitsu Scansnap s1500. It's out of support, and the existing drivers are incompatible with Catalina. I now must pay a 3rd party $100 for drivers or fiddle around with a Linux scanner server or similar. Never again will I pay $400 for a Fujitsu scanner, that's for sure.
It's probably because when faced between paying X for continuous support (where X is a big number) and "we will keep around a few computers for when it's a problem in 20 years", most companies are going to go with the later.
Even if it would make financial sense long term, how likely is it that the person making the decision will be there in 20 years to deal with the mess?
On the other hand, it will look much better on their next quarter results.
It happens all the time, but it's generally not "visible" to the typical HN developer.
PC and peripheral manufacturers in the embedded space often provide availability guarantees e.g., "this version of this hardware will be available for sale at least until YYYY."
Sometimes it matters, usually it doesn't. But it does at least make ordering spare parts easier.
I just watched a Youtube video of the STS-1 landing. He definitely was a happy guy, but it was nearly after landing until he finally exited the shuttle.
Although sometimes the performance when interpreted before warm-up is important.
Testing with CompilerControl.Mode.EXCLUDE in JMH is still more reliable than testing manually, when you don't know if it got compiled or not.
Interpreted code is a case where method handles should be much faster than the generated accessor classes used by reflection - lambdas and method references are faster than an inner class implementing a functional interface before jit compilation. Afterwards, performance tends to be sameish.
I've always been opposed to folks who grumble about suburbs and urban sprawl. I thought that new developments and neighbourhoods meant a growing population and a bigger tax base. I've always lived in the suburbs and love it. I still think there's lots of great things about living in the suburbs, and there will always be demand for it.
I like how the author says that sprawl isn't the problem, the problem is that new developments are large scale, single-purpose, and with no room for improvement or addition.
The graph/map showing how downtown and poorer areas bring in more tax is what did it though. Even just thinking about ploughing in the winter makes it pretty clear that winding suburbian roadscapes are costing the city a lot more than we pay them. That's without mentioning schools, fire halls, garbage collection, etc.
I guess one of the more difficult issues is convincing North Americans that they don't need a private single-family house, large yard, 2+ cars, etc.
For Google, ART seems bigger than just Android. Consider the degree to which their infrastructure depends on the Oracle JVM and the associated strategic risk. As one datapoint, recall the Oracle vs. Google Java lawsuit. How much additional ART development effort is required for correct execution of non-AWT (Abstract Windowing Toolkit) Java applications (essentially, headless server processes)? I know the Java/JVM ecosystem well, but I have not done any Android development. Surely, Google wants control over the destiny of its core software stack.
The article doesn't mention one seemingly huge benefit of JIT compilation: profile-guided optimization:
Perhaps the baby has been thrown out with the bathwater?
Little is mentioned about how ART compares to the JVM. For example, does ART perform escape analysis? Not all object allocations are equally bad. The Sun JVM can figure out which objects may be allocated on TLABs (Thread Local Allocation Buffers) - an optimization which reduces the burden placed on the garbage collector because TLAB-resident objects may be deallocated as the stack is popped. [Please fact-check me as I'm merely a long-time Java developer vs. an expert on JVM internals]
I learned that panhandlers, at least in Chicago, interpret polite negative responses as opportunity and will continue to bother me. So, I have taken to saying flatly, "Not happening." It's not so rude or demeaning that I inadvertently pick a fight, but it's blunt enough to let them know that they're just wasting their time with me.
When I'm in a place where these folks will follow you around, I turn as robotic as possible and answer once (or maybe twice to make things perfectly clear) with a simple "no". I try to leave no room for interpreting playfulness or agressiveness.
