Re: Put that right for you
"They did not have a choice."
Indeed, second sourcing requirements were not unusual back in the day - particularly for "Defense" projects.
1390 posts • joined 21 Sep 2010
"They did not have a choice."
Indeed, second sourcing requirements were not unusual back in the day - particularly for "Defense" projects.
There are other drawbacks to EPIC in addition to recompilation (other architectures suffered from this at various points in their life too). Here's a couple.
* Dynamic scheduling in hardware has more information available to it - and it can of course it can be tuned to fit the hardware to a much larger degree (instruction grouping, uOps etc).
* EPIC pushes you towards massive register files and huge buses in the core, which means longer slower wires, more transistors switching state on a cycle, which all means much slower clock rates in comparison to RISC designs on any given process at a given level of power consumption.
Digital Equipment Corp (amongst others) explored VLIW long before EPIC when silicon was even more expensive and decided to go the RISC route with Alpha. The evidence shows that fabrication was not given enough respect by the guys who came up with the EPIC ISA (that was clear very early on in EPIC's life).
It's an interesting beast though and it wasn't a total disaster, so fair play to the folks who made it work.
Sadly that usage of "Trump" is obsolete. Besides I imagine is trademarked up to the hilt, there is no profit in upsetting the big cheese with the small personality any more than you need to.
You can't blame the customers for this. Cisco could ship their kit secure by default - and let the pros and wannabes break security as they wish. If they really can't manage that they should probably stop selling stuff they don't understand and can't build properly.
"Can't recall anything ever wrong with it? It outperformed Linux as an NFS Server last time I tested it!"
Quite the reverse in my experience - a 486DX2-66 with an IDE drive running a 1.2.x kernel spanked the NT 3.51 and NT 4.0 installs on a Pentium Pro with 8x the memory, 4x the clock speed and 4 way striped UltraSCSI drives (Adaptec 3940UW). NT had some serious flaws with respect to file system performance back then.
In fairness I can accept that your mileage varied, we had some fairly extreme use cases - zillions of little files and lots of massive (for the time) files, nothing "average". :)
The POSIX subsystem was a huge disappointment, mainly because the performance conform to a typical POSIX/UNIX coder's experience. Processes were slow to start, context switching was very slow in NT, UNIX apps tend to presume the opposite, Paging & Memory mapped I/O was cripplingly expensive too.
MS have moved NT along over time - but it's been rare that NT has been the quickest or most efficient option. YMMV
"what's wrong with Doc Smith?"
Not much IMO, but I suspect the pipe-smoking, somewhat outmoded portrayal of women and genocide may not sit well with current audiences. :)
"I'd pay to see a decent Lensman film."
Have an upvote. Loved the books, I'd like to see a Skylark film too. :)
If Intel had any sense they would let the brand name die and invest all that lawyer money in something more productive than preserving a toxic brand name associated with a shit product.
"The problem is not their age, it is that they are wilfully thick, stupid politicians(*) pandering to the lowest electoral denominator."
There is no evidence to indicate that the lowest electoral denominator gives a flying fig about encryption. There is more evidence to indicate these clowns just want a competitive advantage over the proles baked into law.
"At some point politicians will understand that encryption is just maths at work and trying to restrict it is self defeating"
That is wishful thinking. :)
These folks have never at any point in their lives had to understand encryption to get what they want. Why would they start learning now when barking orders has worked so very well for them all their entitled lives ?
"Distributed concurrency is fairly new and not solved as much as people expect it to be."
Depends on your definition of "new", folks were working on this problem before ARPAnet first started punting bytes around the place. Leslie Lamport et al wrote the "The Byzantine Generals Problem" paper ~1980, and it was not a new problem for them to solve even at that time...
From my point of view, academically, distributed computing/parallel processing is fairly mature, there are plenty of robust models and papers out there, the problem is that folks invest their time in looking for silver bullet frameworks rather than reading papers and applying grey matter.
"Upvotes should disappear after a year and eventually old answers will sink and bright shiny new code will appear to take its place."
That's not a bad suggestion, but I'd like the option of specifying a time range. There is some perfectly good old code out there that needs love too. ;)
I fear that if I were to enforce the third rejection criteria ("probably cleverer than us.") pretty much everything would be rejected. Would 2 out of 3 suffice, or is that too little hitlerism ?
"I much prefered EDT and TPU, personally."
I did enjoy using TPU, but the joy was derived from the sense of achievement I got from mastering something awkward. Once I got stuck into Emacs/vi/sed/awk I never looked back. :)
I think Trump is more likely to pan out as America's Yeltsin.
... because there is practically zero material penalty for doing so. If a corporate shill faced a high probability of jail time I am fairly sure their product development would take a very different direction.
The worst that might happen here in Blighty is that you may get a stiffly worded letter from the ICO (if at all). If your crime is big enough I guess you may face a panel of techincally illiterate MPs who pitch softball questions and eventually land a fat contract at tax-payers expense to provide a functionally useless system that rapes the further erodes and the tax payers privacy.
"NT4 was a decent OS and the only viable alternative"
In my experience NT4 was definitely was *not* suitable for any business that cared about security or data integrity. One of the show stopper bugs we discovered in the first week of deploying it was the corruption of compressed read-only files accessed by NT 3.51 SMB clients... Linux + Samba was better even back then... YMMV.
Michael Morell: "In the intelligence business, we would say that Mr Putin had recruited Mr Trump as an unwitting agent of the Russian Federation."
My coat is the one with the "Spotter's Guide to Black Helicopters" in the pocket.
"I doubt that committing genocide every day is sustainable, surely they would run out of children to murder?"
The CIA "World Factbook" estimates neonatal mortality rate in the Gaza Strip to be 17 per 1000 vs 3.5 per 1000 for Israel as a whole. Something isn't right there.
"Why that Russian tweet sounded so much like it could have been written by Trump..."
It would make sense given that Trump seems to be doing Putin's dirty work these days.
"That is the interesting thing. He isn't a politician."
He is a politician by definition, and has been since he put himself up for election.
"I can't wait until he starts actually getting things done that help our country, from the office, and these little snowflakes (who have only known Obama's failed leadership most of their adult lives) "
Obama did pretty well considering he had the houses stacked against him, he was handed a administration that was massively overspending in a recession and managed to fly the crate straight & level. By contrast Shrub's administration with the backing of both houses blew out the federal budgets and presided over a global recession. I don't see any reason to expect the US + world to fare any better under the Trumpton administration with the backing of both houses.
I honestly hope I am wrong, but I suspect the little people who voted for Trumpton won't see their circumstances improve over the next term. I will be happily surprised if you can prove me wrong in 4 years time.
"Like you, I would expect it to be illegal."
Since when has that stopped a government doing anything ? In the *real* world rather than the airy fairy legal world a Government is big enough to ignore the law or change it if they are feeling legally challenged.
"Solaris has always struck as Unix clone/derivative with nothing special about it except the availability of paid technical support from Sun."
In fairness to Solaris it did bring LDoms & ZFS to the table - which were fairly special at the time of their introduction.
"As for "how am I meant to patch this when I can't get online?" - this is no different to those times when your network card driver would go kaput and you'd need to download a new / updated one. "
in the good old days I'd just rollback the previous update... Or failing that hunt down a recovery floppy/bootable CD/USB stick with Linux on it. Thankfully this still works today. :)
"F'king hell, we can't win."
Nah, you won my heart, thanks for the heads up. :)
"publicly announced partnership where both companies stated as fact that Red Hat would carry out all support of their products on Azure personally using Red Hat staff in shared call centre facilities? "
I am guessing that you understand that Support != Operate != Developing a Product. :)
"There have been few if any vulnerabilities found in the other Azure services which were set up by MS."
By the same token that doesn't necessarily mean that there aren't plenty to be found.
"It's therefore likely this was a self inflicted wound by Red Hat rather than MS not setting it up correctly."
That's pretty unlikely IMO given my experience of Red Hat support. However given my experience of Microsoft's approach to support, and their proven track record of prioritising "time to market" over all engineering concerns, I think it is far more likely that Microsoft's engineering staff have been ordered to roll out a RHEL on Azure Proof-of-Concept to production.
Ultimately it's a Microsoft self-inflicted wound we're seeing here. As a potential customer I would be questioning the processes and financing of Azure at this point because their processes are clearly inadequate, their are clearly incompetent and they are clearly failing to budget enough for mitigation as well judging by the miserly bounty. Mistakes happen, but this is a production system folks - this kind of schoolboy config screw up should have been caught at the PoC/dev stage.
"It's a long time - over 35 years - since I worked on a multiprocessor shared-memory architecture. Presumably HPE reckon that they can implement monitors or semaphores - to control access to shared memory - in such a way as not to adversely affect the Machine's performance."
The state of the art has moved forward a little in that time period (lockless algorithms, LL/SC etc) - the fundamental problem of data sitting on the end of a high latency pipe hasn't changed though. :(
Seems like HPE have tripped over some Denelcor HEP brochures while clearing out some greybeard dens.
Love to play with something like this, but I don't think it does anything to fundamentally change the way systems are built or perform at the base level. The system software and software architecture that sits on it may well deliver a difference - but I'm somewhat sceptical about the chances of that being an advantage that would uniquely apply for this particular assemblage of components.
It really doesn't matter if you are logically moving processes to data or data to processes, or keeping both in situ, data still has to travel down those long distance high-bandwidth links... Those long distance high-bandwidth links will still need plenty of Watts in silicon to drive them regardless of whether the data travels down fibre or wire. :(
Have an upvote DougS:
"Modern CPUs have so much going on that the more complicated decoder required for x86 is simply lost in the noise in a multi billion transistor chip."
I'd still rather that chips did not have complex decoders simply because it makes design verification difficult, and that is is important because I want bug-free chips... I want bug-free chips because it's hard to replace a chip soldered onto a board - or buried inside a rack. The x86 errata sheets & documentation around the various permissions mechanisms tend to be byzantine - and Intel have a rather ugly track record of pretending security vulnerabilities in their chips don't matter. :(
The thing that ARM chips typically lack in comparison to their Intel competition is memory bandwidth - and that requires to you drive a lot of wires at high frequencies - which burns a lot of juice. My suspicion is that ARM chips with equivalent STREAM bench figures may actually burn a comparable amount of power to an Intel chip...
"It won't. Emulation is slow. It's not gonna happen. She fell for this once before, when reporting on the release of the original ARM based Surface."
Emulation isn't necessarily "slow" these days - and hasn't been for decades, FX!32 ran PKZIP 1.5-2x quicker despite the host processor having a 30% clock speed deficit. Typical desktop apps make a lot of API calls - those can be run native, and of course code tends to spend a lot of time executing loops - so caching translated sequences of instructions yields big benefits. Folks running code on JVMs benefit from those same tricks every day - it's not rocket science any more.
Of course it's better not to require emulation in the first place - but old x86 binaries developed for 300Mhz P3's should run just dandy on a 2GHz ARM these days.
"Portland for a protest meetup"
Dunno about protesting, but the beer's great there (or at least it was the last time I visited). :)
"I'd love to see a whitelist-based approach to antivirus. It's good enough for firewalling, and that already works way better than any antivirus package I've seen."
AFAICT SELinux delivers that - and more, without the disk thrashing. Labelled IPSEC + SELinux goes a bit further - giving you a way to identify remote processes and decide if you trust them or not too. I am surprised no one else has mentioned it yet.
"I hope you weren't put off by that! I was just speaking to you in the language of your hero, Linus Torvalds."
Nah, that was Steve Ballmer, surely.
"That or while I wait for the grammar police to act on that apostrophe atrocity…"
I can live with that. :)
"The Note 7's ability to double as a cooking surface for my morning bacon and eggs whilst waiting for the bus was an invaluable feature!"
Apple have already shipped phones that have this feature, maybe you can toast some popcorn with it while the Apple warms up it's lawyers for another round. :)
"There's no need for ECC"
Parity should be for everyone, not just farmers IMO. :)
"Everything, sooner or later, becomes a boat anchor."
MS Surface widgets will make lousy boat anchors.
"Also APIs change over time - consequently the application also needs to change."
Wrong way round.
APIs might grow but should not change or remove existing functionality therefore the application should not need to change except to take advantage of such extended functionality"
You say "should", in practice that just can't be relied upon. There are APIs out there that are insecure by design - what do you do with those ? If apps are tied to those APIs they need to be killed or changed - in my experience the latter works better over the long run (YMMV).
"Nobody who wrote a piece of code 10 years ago is going to bother to keep the libraries up to date."
I guess shared objects ld.so and the weird symbolic linking thing in /usr/lib passed you by then. Also APIs change over time - consequently the application also needs to change. Also, realistically, once you've changed the run-time configuration you should do some regression testing.
"The authentication bug was for an information service & the info that can be gained isn't particularly useful, certainly not a critical prior and not classified by SAP as such."
1) The flaw was *re-introduced* which tells you that SAP are failing to use regression tests to verify that vulns stay fixed. This is a basic process problem that is *likely* to afflict every release of every product they produce.
2) Authentication bypasses give an attacker a platform to launch further attacks within a "trusted" domain, this is not a good thing.
I distinctly recall being told that Open Source (that worked vs vendor stuff that didn't) was not an option because there was no vendor to sue or coerce into fixing the code. Presumably we'll see SAP litigated to death and the source code distributed to the customers in lieu of working product... Naaaaaaaaaaaaah.
"And actually, OS X (now MacOS) predates Linux since it goes back to NeXT. So you can't even get things correct."
... Which in turn is based on the MACH uKernel with some more modern (Free?)BSD userland ...
Personally I'm glad corporations can take decent mature software and incorporate it into their products, the alternative didn't look too clever in the guise of NT 3.x... Sure Windows got better - but years of Not-Invented-Here seems to be have bitten hard in the form of 10.
I'm all for corps reaping their rewards, but equally I would like to see said corporations cut a bit of slack to imitation of good ideas though - just from the point of view of keeping the field open for innovators.
Auditing the inards of a -11 will be few orders of magnitude simpler than auditing the inards of modern SoC. With x86 you have zero hope of auditing it down to hardware level - there is a ton of hidden state in those things and a smorgasbord of security models which all interlock intricately and are documented in prose format. I know which I would prefer to audit. :)
"The message is that everything - applications, network, OS - is cloud and is managed from the cloud."
Sure it is, and virtual Umpalumpas do all the scripting & monitoring too because employing human people to admin a mass-surveillance system is just too risky. :)
It wasn't quick, so there was no love for QBASIC. :)
"yes, both people who allow automatic updates and people who manually scrutinize and approve updates are vulnerable to zero day exploits."
Right, so the update-sceptics are no worse off then.
"your logic is like saying a knife-proof vest or a bullet-proof vest for a policeman is "useless" because it doesn't protect him from a V-2 rocket falling on him from out of the sky."
You may be terrified of zero day exploits but I can assure you that they are nothing "like" ballistic missiles, they are simply vulnerabilities that the vendors have not patched yet. If you are very afraid you could simply disconnect all your machines from the internet and make sure you scan all your imported files for nasties in a test environment first.
"ironically dear old auntie or granny with her computer set to accept patches automatically is LESS of a disease vector"
I doubt there/s much difference in practice, just look at how old some of the "zero days" are, case in point font rendering vulns that allow an attack to run code in ring 0 existed in NT and it's derivatives for over 20 years - despite thousands of updates (and drive by attacks). There have also been updates that introduce new vulnerabilities, the OpenSSL Heartbleed vulnerability is an example of new functionality bringing new vulns. I'm using heartbleed as an example because it's not all MS's fault, and in that particular instance I dodged the heartbleed vuln simply because I felt the risk posed by the update was not worth the reward (functionality that I didn't want).
If you care about vulnerabilities there really is no alternative to research and paying attention to what the updates are doing - because history shows that trusting a single vendor to fix every single hole in a two decade old piece of bloat-ware just isn't enough (and vendors make mistakes)...
". and then your computer gets owned by a 'botnet. and then you're yet another dumb motherfucker who is part of the problem."
Strangely that's exactly what happens with zero day exploits, except in your utopia *everyone* is a dumb mf who is part of the problem.
"Is there a way other than NUMA?"
NUMA is a consequence of real world physics. The only boxes that dodge that issue are ones that don't share memory and ones that slow memory access down to the slowest (old/cheap SMP boxes). FWIW accessing DRAM on a single core box hasn't taken uniform time since fast page mode became the norm (early 90s) either.
In terms of other ways: Re-architect your software to stop requiring threads & big address spaces (Java apps tend to operate in this mode) - and stock up on single socket low-core count boxes with huge caches.
"Cyber attack in 2012. Arrested in March 2015. Sentenced in Sept 2016."
Coincidently that fits in with the timeframe of the massive breach Yahoo! attributed to a "State" actor. Funny that. :P