Re: I GOT 1 wordz 4 all u traytowers!!!
You are Vladimir Putin and I claim my $5.
1617 posts • joined 21 Sep 2010
Minimizing dependencies is the rational way to minimize the vulnerabilities that are pulled in. The vast majority of code I work with pulls in a vast amount of unrelated and unused code, the proportion of stuff actually used tends to be tiny - and worse still quite a few of the imports are redundant - they are replicating stuff that's already available in the stdlibs or other imports.
YMMV, the stuff I work with on a daily basis has been worked over by a team with a high turnover of staff where the focus is very much on adding new stuff rather than fixing technical debt for over a decade, so I recognize that my viewpoint might not fit everyone's situation. :)
It's interesting that the report identified the imports brought in by containers as a problem - it's an issue that has been glossed over by too many people for too long. Glad they brought that up because I am seeing containers broadening and deepening the pool of dependencies in practice because Devs now get to pick and choose what bits of the OS they want - and it's rare that two of them agree. :)
"You are quite right. I'm talking about emulation, and the pain that would happen when what you're emulating is a virtual machine host."
Oddly enough that is exactly the problem that has been solved many times over from the 80s to the current day. Even today's common-or-garden VMs emulate (a surprising amount of) PC hardware sufficiently to host Windows 10.
While I it doesn't belong in the "trivial" bracket, emulating the CPU isn't as hard as you may think - as evidenced by the last 40 years or so, and Windows 10 and it's apps don't require cycle accurate emulation for everything either - as evidenced by the fact they run under VMs - even with PCI(e) passthrough quite happily.
"ranslating all of Windows's instructions from X86 and X86-64 to ARM will require a lot of emulation, and it will either take a lot of processing (meaning it runs slowly) or require a massive cache of pretranslated instructions as you have mentioned, "
I have to respectfully disagree with you on that point - based on what I saw over 20 years ago with NT x86 binaries running quicker on an Alpha box - and the current state of the art with respect to VMs and JVMs. :)
"Remember that Windows 10 weighs in at eight gigabytes, a lot of which is X86 binaries. "
Another way to look at this is modern CPUs have a certain amount of cache - and a very high penalty for accessible data in the DIMMs. Windows 10 like all other software executing on modern CPUs, has to be kind to those caches to get close to acceptable performance, this means that the code is tuned to make those caches effective, which in turn helps you if you're loading up caches with translated instructions.
Additionally - most, if not all AMD & Intel processors are actually RISC style machines under the covers - they have a front end that decodes (aka translates) x86 CISC instructions into micro-ops... The emulator would be doing something similar...
In summary I don't think it's a stretch for Apple to make on the hoof translation work - but I think (very pragmatically) they've taken the approach of generating fat binaries instead.
"The worst case scenario is ARM-compatibility layer virtualizes X86, VM host runs in X86, tries to run another OS in X86, and probably screeches to a halt before the application can even be started. It will depend a lot on the companies producing VM software."
Err, I think you're talking about emulation, and it's pretty old hat now... See SoftPC (late 80s), FX!32 (mid 90s), simh etc.
FX!32 made a big impression - it was a emulator layer for Windows NT on the DEC Alpha that ran x86 binaries as quick on a (very low end bargain basement) 166MHz Alpha as they ran on a very expensive maxed out 200MHz Pentium Pro box. IIRC it translated code on the fly & cached the translations - so you didn't pay the translation penalty over and over again - like Sun's HotSpot JVM.
The mini/mainframe vendors also shipped emulators for their legacy lines - some implemented in hardware, some software and some a mix of the two.
Juding by the track record of these particular Senators, the GOP and the Administration, I think it more likely that their intent is to criminalize privacy and enforce the legislation in an arbitrary and malicious way rather than bend the laws of maths and physics.
"I find it somewhat amusing (and a trifle sad) how many people in this forum try to brush the entire population of the United States with a single brush ..."
I did the opposite, I selected a very fine brush to highlight an 'induhvidual' case... The GOP are the folks applying the broad brush dipped in mud at the minute.
Sadly true. My interest in what goes on in the US is because UK government foreign policy has pretty much been dictated by the US government. Although that does seem to have evolved a little - the UK cabinet now takes it's orders from a bunch of shady think tanks that are set up & funded by US & Russian billionaires instead - I guess they cut out the middle man which makes sense if they already own the US government from top to bottom.
"If you have actual proof of such wide-spread fraud, please alert the authorities ... and the Press. Posting about it here does absolutely zero good."
Fair point, but I suspect the poster may well have been thinking about such as "Leslie McCrae Dowless Jr" - he has been indicted recently. Funnily enough it's actually quite difficult to get search results for this stuff because of all the mud stirred up by the Republicans - the majority of hits reflect their narrative rather than the fraud investigations and their outcomes.
Kinda sad seeing a key Intel customer, AWS, flounder around trying to fix Intel's bugs instead of leaning on Intel to actually fix them. AWS are between a rock and a hard place - they either replace the hardware - with the unavoidable chance that the new hardware will also be broken, or they implement performance killing hacks on their heavily utilized shared boxes... Gee, maybe putting all your eggs in one basket was a dumb idea after all...
I worked in the AV installation trade biz for a while - where I got sample a very wide range of gear. The weird thing was - while we were all bowled over by the 10/50/100K speakers, in a blind test most folks preferred the (relatively) cheap Rega R3s over everything else (including the R7s). I'm fairly sure no one is going to claim the R3s are the worlds best ever speaker - but they just sounded nicer than the other gear. In the demo room customers tended to insist on starting at the high end and worked downwards - they rarely got below the 5K mark. On occasion they'd make it down to the R3s - and listen visibly entranced for a while - and then move back to the expensive gear that pushed more Watts... :)
"Plus you can do a ,lot of great things to transform XML data using XSL."
Yeah, that's cool and all, until you find that the folks who wrote the transforms can't actually maintain them because it's "too hard" after they've spent years adding cruft and not writing any tests to validate their changes.
Disclosure: I have been savaged repeatedly by rabid XSLTs.
Over the years I've found that validation against a schema doesn't really help that much in practice, it's another complex pile of stuff to parse with more bugs waiting to bite your ass. Using as simple-to-parse format as possible (to minimize the valid permutations of input), writing unit tests and integration tests to go with it has proven to be more effective the long haul than adding yet more attack surface to the input handling code.
The "small disadvantages" of DDT that you glossed over include it killing ff a lot more than mosquitoes and persisting in the environment (and accumulating in larger organisms) over a long period of time. IIRC it takes 30-40 years to breakdown... Quite a few people see those as huge disadvantages - not least the folks who want their crops pollinated...
"According to the article he wanted to strong-arm his employer into taking "climate action"."
I think that's a legit call when you take into account that Amazon is heavily into the Data Center business in the form of AWS - in addition to box shifting lots of shiny luxury items to the masses.
AWS runs on a huge amount of plant that is continually refreshed and burns a lot of juice. Furthermore AWS tends to run I/O intensive applications on Virtual Machines - which tend to impose a heavy penalty for I/O - thus increasing the amount of energy to run those I/O intensive apps.
Companies impact all aspects of our individual lives and the environment we live in - but very few of them actually take responsibility for that. Furthermore there are plenty of disincentives to price the downsides in - as the 2009 crash illustrated so vividly. Hell, it took over 40 years of activists to kicking up a fuss to get DDT usage under some kind of control (note: it still isn't actually banned outright), and there's a some evidence that we're facing a similar problem again with Neonicotinoids.
I'm all for people having a roof over their heads and a comfortable life - and making money to facilitate that - but I'm also for folks taking responsibility, honestly considering the downsides to society and the planet as a whole, and moderating their activities accordingly...
TL;DR version: Narrowly focussing on the money is simply not sufficient to run a society or a planet.
Not really sure why you're so anti-Koala preservation - did one bite you in the nuts on a nudist beach ?
The WHO are a coordinating entity (at best), they don't have a bunch of jackboots on the ground to bust asses - or the ability to apply sanctions at the drop of a hat. All they can do is to The buck stops with the power brokers. It's hardly a surprise those power brokers that dropped the ball are blaming the WHO, they haven't got anyone else to blame having shit-canned the advice and experts who advised them to prepare for pandemics before Covid blew up in the first place.
It's actually pretty easy under Linux too. :)
You run the heavyweight processing on Linux servers (because it is actually a lot cheaper to run at 10-100K node scale all your weird rants about FOSS aide), set a few aside for hosting Windows as guest VMs. Put 10-100K (Linux) remote desktop terminals on people's desks and they really don't care or notice the difference. It's not rocket science, and it's being done - at a lot of large multinationals.
"Fully functional Linux embedded within MS Windows presents opportunity for enterprise, public sector, education, and individuals, all currently in thrall to Microsoft, to explore and evaluate alternative non-proprietary software without trauma of full system change with possibly expensive reversion should the outcome be unsatisfactory."
Strictly speaking that has been possible for a very long time - whether it be by CD, USB stick, VNC or whatever. The only material difference here is that you've got Microsoft embracing and extending Linux - and subjecting it to the hit and miss joy of Windows Update. I don't expect much to change, people have got over the shock of Phone apps and Web apps now, and that is pretty much going to kill off the majority of the Windows desktop market (for better or worse) - this is simply Microsoft trying to stay relevant to server side developers.
One wonders if IBM is mired in Multiple Agile Backlog syndrome which is the usual end state of Agile in a large corporate concern. Specifically multiple backlogs, one for the devs doing the actual work, one to present the state of play to the upper manglement, and another that holds all the technical debt that isn't allowed to see the light of day because it looks "untidy", with the devs having to enter everything in triplicate...
The version of JRE that you're using is a serious problem, but containerizing it only solves the trivial cases.
In the case of the real world non-trivial Java applications we deal with (aka enormous multi-threaded monoliths with literally hundreds of dependencies), it's actually impossible to get *all* the dependencies to work on same JRE... Splitting that lot up into different processes (laughably called "Microservices") is often not pretty - and involves some serious effort and (usually) a big hit in performance.
Maybe in a few years time the dust will settle, everyone will have caught up and it'll be as easy as porting a bit of C/C++... YMMV ;)
"And on the other other hand, until recently most people didn't realise just how stupid Boeing management and their regulatory colleagues could be."
In the case of Boeing Manglement and the FAA being self-serving pays better than being diligent or stupid.
So people's votes don't count if you don't like their choice, but the vote of a square mile of land counts as it voted the way you wanted it to. Hope you enjoy your Monarchy, the Gimp suit is for you and your Monarch's enjoyment.
There is an easy answer, but the vendors and "power users" aren't going to like it.
The hundreds of megabytes of Flash, the tweaking guff, weird Windows backwards compatibility widgers (eg: "A20" config), PXE boot loaders can and should get shit-canned. This allows a customer to have some confidence + control over what is actually executed and some assurance that their M/B can't be perma-bricked by some tosser at the other end of an Ethernet cable.
This could be achieved very simply and cheaply by replacing the Flash memory + fscking BIOS / UEFI with a tiny *ROM* bootloader that loads a few bytes off a bootstrap storage device (eg: a MicroSD card on the motherboard) and executes it. That ROM bootloader should do nothing other than load those bytes and execute them - everything else is to be done by the code on the MicroSD card that is firmly under customer control.
"The AoA sensors are not critical in that the plane can fly just fine with them as long as the pilots (and the flight control computers) know to ignore that input modality altogether with a failure"
... Yet AoA seems to be a recurring theme in airliner pilot error/accidents - it was a key parameter in AF447 accident as well. From this armchair pilot's point of view it looks like you really need some working AoA instrumentation to fly the aircraft "instruments only" in bad conditions.
We knew the context switching on Intel gear was pretty bad, but had no idea that AMD was so much better - thanks for that ray of sunshine. In some cases post-fix we've had to reduce the process count on a box, as if the app has suddenly become memory bandwidth limited despite running on hardware that delivers more bandwidth, expensive context switching would explain that anomaly.
With respect to Intel's misfortune, it was a result of design. AMD took the view that they shouldn't evaluate permissions *after* doing the accesses. Intel chose to evaluate permissions during/after access - presumably to mitigate memory access latency. Pretty sure Intel aren't unique in taking that option, there were quite a few papers on reducing memory access latency in the mid-late 90s.
"Frankly, I'm hoping AMD will now casually wander into the server market as well, where performance per watt matters as much as just the raw performance in itself"
Seems more likely to happen than it was a couple of years ago... Some folks who consume a huge amount of compute have noticed a drop in "per-core" throughput on the Xeon boxes across three generations in a row that isn't being offset by "TurboMode", cache size increases, or the increase in cores per cubic foot. Some of it is down to poorly tuned code, some down to chip errata, and to matters even more fun the performance varies pretty wildly from box to box or even run to run on the same box. Makes tuning very tiresome for everyone involved, and all the effort that goes into tuning new boxes to make them nearly as quick as the ones they replaced isn't going down well.
The "stable performance" thing is critical for big workloads - you need to be able to predict how long stuff will execute in order to hide dispatch latency and startup costs... Throughput that can take a 25% hit on 100% loaded boxes depending on the phase of the moon makes life much harder and more expensive for everyone.
"I would be very interested in an explanation and description of what the jaffa had done for Putin lately."
In fairness it's hard to tell when Trump has been busy destroying every record of communication between himself & Putin. But there is a nice fat money trail and a few instances of Trump deciding to exchange classified information with Russia on a whim - the sort of thing that folks get locked up for many years normally.
Withdrawing from Syria and repeated vetoing any action on Ukraine were two pretty big favours to Vlad. Tearing up the nuke treaty also helps Vlad too, as the classes of weapon affected just happen to be the ones that Russia has expended the most effort developing - and the ones that fit their strategic needs far better.
"Now sending electrons through layers of silicon to implement an abstract instruction set is definately science and /or engineering."
I learnt a lot (mostly good) from VLSI chip designers - who happened to use C for a wide variety of tasks in their daily grind. In my view they were much more adept at working with abstractions than pure comp.sci folks - borrowing from comp.sci, maths and physics to find a pragmatic (and usually elegant) solution.
Those folks took a very different view of security too, tending to work on the physical principles - eg: if accounts share access to the same storage you have to assume the info will leak (many of them cut their teeth cracking minicomputers for extra storage/compute time :P). They used TDD for everything, big or small, (there wasn't a label for it back then - it was basic engineering practice) and their transistor counting instincts ensured that the code was lean and cruft free.
Three decades have passed since, things have moved on quite a bit - but I think software still has a lot more to learn from hardware, especially as folks seem intent on chewing up more memory forcing the data to travel a few mm further than it needs to (looking at you Java), which can easily add up to lots of wasted kilowatts at the data centre. :)
At most datacenters I've worked with entire boxes are swapped out - the broken one taken away for further examination/repair/exchange/disposal. As long as they have nice self-sealing connectors for the plumbing they'll be fine.
The boxes will be substantially more dense than normal ones though - the oil will be heavier and they appear to be packing a lot more components into the same volume than a vanilla box... Perhaps professional wrestlers could do the job - they should be well practiced in grappling with heavy oily units. :)
Biting the hand that feeds IT © 1998–2020