Yeah, I started in the 3.1 days, so AMT was already there. I still maintain that the ME kernel (prior to the push to get on to tiny IA and Minix) was pretty damn secure. I also maintain that a sub processor with a kernel based os running apps for system bringup is a good idea. It allows not having to build dedicated hardware for all the separate functions on a motherboard (power management, USB init, SATA init, etc.) the issue is making this kernel have *any* outside world connection other than an output only health monitor BAR or similar.
ME Ver 9 saw an architecture change (new kernel, new CPU core). Not actually sure what "generation" that maps to, as MEINFOVer is not the same as CPU gen ID
Actually on ME9 Intel changed the kernel. In ME6 they changed the platform layout.
* ME < 6: GMCH northbridge and southbridge. ME lived in the GMCH and had full access to RAM even in S5 (off) system state. Kernel is based on ThreadX. CPU is ARM core. * ME 6-8, same kernel, but moved to PCH (formerly southbridge) and the CPU gined the GM part of GMCH. Northbridge removed from platforms. ME loses access to RAM in all states besides S0 (on) and has to make do with PRAM on PCH. * ME9+: ME now runs on Minix and Quark CPU. Vulnerabilities become an issue. * ME10: internal struggle for dominance between kernel and AMT teams (based in US and Israel respectively) leads to departures. (including mine) * ME11 (12?): US team is disbanded.
So, it is a cloud then. The system delegates the compute resources and harvests them when free. It's dynamic and elastic based on demand (and total install size).
But does that make it a bad thing prima facie? I'm also in the "Liberal Libertarian" camp that understands "get a job" is not a viable answer to everyone in society. The system we have now is deeply flawed, and I honestly don't know how to fix it. I do believe it is unfixable in our current political environment.
how is it not a cloud? If it follows the same architecture, layout, and usage model, then it's a cloud. A self hosted one, sure (and I would expect nothing less than self hosted from these agencies!)
Yeah, "disagree and commit" looks great on paper, but assholes gonna asshole.
And there ain't no system that can stop them. My exit was a railroad job for taking one of said assholes to HR for ethics violations. Like I said, I walked out a martyr, because while I no longer am employed there, about 50 other people are, and are no longer being abused.
When done correctly and with trust it can make for a great team and stupendous levels of output, plus it builds trust even deeper between leadership and team.
I have seen the flipside (in fact I was the one who said "No because of Foo which will likely cause Bar and will cause Baz and if Fizz also happens then we're going to have issues"). Said manager actually did try to toss my ass under the bus for "not being clearer about my reservations". My response was the 5 page document I initially developed that was if anything over verbose. Interestingly that manager left the company within 6 months of that kerfluffle.
In fact I believe paraphrasing Regan's "Trust but verify" into "play by the rules but keep your ass covered" is apt for any job.
I keep a "Pearl Harbor File" at home that has full documentation on everything I think may be needed. I use a portable apps install at the office to manage the live copy. The one time that there was the potential of legal action said file had my ass so neatly covered that while I still left the company and was flagged non rehirable (over my then current boss's strenuous objections) I was handed a slightly larger than normal severance package to simply go quietly into the night. My lawyer and their lawyer agreed it was best for both, my wallet agreed as well. The best part is that the line staff all knew why and I walked out of there a martyr... having already been offered employment by one of said line staff that moved to another company.
True, but that doesn't mean that you shouldn't try... you just need to be mindful that you may be in an echo chamber and attempt to break out of it.
I have found that anyone I've worked for I have been blunt and not a yes man and it has mostly gone well for me. The two times it really didn't I was saved by being shoved out because not long after I found that said team / company had severe issues and was disbanded / closed up.
Now, there is a difference between being honest and being obstructionist and that's where a lot of people screw up. My old employer had a policy of "Disagree and commit" and it makes for an awesome workplace when management and team embrace it. Management/tech leadership gets feedback, yes's and no's and the reasoning behind them. They take this information and act based on it. If you were a "no" and the decision was to move forward anyway then you commit to seeing it through, even if you don't think it's the best idea... same the other way, if you were a "yes" and it's decided to change directions you drop it and change directions.
When done correctly and with trust it can make for a great team and stupendous levels of output, plus it builds trust even deeper between leadership and team.
I had (still have) one of these beasts: https://en.wikipedia.org/wiki/... Tucked away in a machine that's almost never on is one of these drives (with a spare in a box).
And any company that tried to actually unify all the related OSS project pits into a coherent single user/server application suite would want to be remunerated for the effort to do so and maintain it... at which point it's going to cost as much as Outlook/Exchange so...
I completely concur that tests on all inputs (external to the system) are mandatory. By external I mean any input from outside the code. Last big project I worked on there were two "rings" in ring 0 code, one that faced userland and one that only faced ring 0 code. The former validated *everything* the latter, not so much. Embedded system where memory and compute cycles were at a premium.
Why can't Linux be easy? I mean seriously, I think this illustrates very clearly why there has never been a "Year of Linux on the desktop" no matter how much we all want it. Linux on phones ala Android is incredibly popular because it's *easy*, even if some security ground was given up to make it so. There needs to be an enterprise friendly and home user friendly Linux that "just works" and has common business tools and home time wasters that regular folks use and want. Only then does it have a Hell's chance, and even then it's doubtful because of inertia.
Ubuntu very nearly has this licked, largely stable system, particularly LTS, easy repo installs including closed source blobs (even if you hate them, they increase usability, and thus potential market adoption), and widely available with broad platform support, but even with that it hasn't cracked the desktop.
I suppose you also think a spare tire is over engineering.
Technically it is. Over-engineering is also known as planning for failure, or safety margin. Similar to SSDs over provisioning the memory array to make up for expected failures. You know that 1TB SSD you bought? It's actually 1.25-1.5TB of raw capacity, but because they know cells will fail, rather than having drive space decrease over time they just pre-reserve a block.
In Space-X's case the over engineering of an "extra" engine increases the expected reliability, much the same way the SSD's over provisioning does. The difference is that lighting an engine after launch after you detect it's needed would be a massive design issue (and additional risk) so they launch with the whole load running. Kind of like if the 1TB SSD shipped as 1.5TB with a 5 year guarantee to still be at least 1TB.
I am reasonably new at my current (very small) company. I am the second (and still not fully dedicated) QA person. I came from 17 years at a multinational Corp with huge QA.
To say I encountered culture shock is an understatement. I have started implementing things like automated regression tests, and Fuzzers. My Fuzzer based tests break the shit out of things and the devs look at me with the "why would you do that?" look. They still have to go fix the issue though.
I was thinking the same thing. Mishaps on the test stand is what the thing is built for. Even a massive explosion with all equipment lost is a success because it thus did not happen on a launch pad where in addition to the lost equipment you very well may/will lose: * The Payload. * The Launchpad Facility. * The actual Launchpad. * Lives. * Delay to future launches of unknown duration because of aforementioned damage.
Sure it's a suboptimal success, but it is still not a failure.
Yes it is mechanical. For a highly analytical person it is easily graspable, because that mechanical-ness *is* analytical. My issue isn't even with alternate teaching guides, it's that the implementation is *shit* and that's not helped when there is no context for the problems your kid brings home as homework.
To add to the shitfest of CC, many of the teachers don't like it, and as a result fail to teach it very well. That leaves the kids confused as all hell.
I know you're trolling but there is actually a decent point here. There are people who just can't get classic long division, does that make them bad?
Or is it rather that instead of chucking out the entire system they should maybe consider that there are many diverse and distinct learning styles and use the one(s) suited to the students? Also, the IEP counselor would disagree with you as she's just as baffled by the new crap (as was the teacher teaching it in the first place, who was openly hostile to it).
Slashdot Mirror
Yeah, I started in the 3.1 days, so AMT was already there.
I still maintain that the ME kernel (prior to the push to get on to tiny IA and Minix) was pretty damn secure.
I also maintain that a sub processor with a kernel based os running apps for system bringup is a good idea. It allows not having to build dedicated hardware for all the separate functions on a motherboard (power management, USB init, SATA init, etc.) the issue is making this kernel have *any* outside world connection other than an output only health monitor BAR or similar.
you mean late 90's? Tech bubble popped Aug 21, 1999.
So a follow-up...
Think when the bubble pops it's all going away? Or do you think it will return to a baseline value and stabilize?
it'd be a dual and a couple cents.
there is not much memory available to it, and it's a pretty limited Quark core (or ARM if older than ME9).
There is a remote exploit in AMT (one of the apps for ME). So if you have AMT you're remotely exploitable if it's not disabled in ME.
ME Ver 9 saw an architecture change (new kernel, new CPU core). Not actually sure what "generation" that maps to, as MEINFOVer is not the same as CPU gen ID
Actually on ME9 Intel changed the kernel. In ME6 they changed the platform layout.
* ME < 6: GMCH northbridge and southbridge. ME lived in the GMCH and had full access to RAM even in S5 (off) system state. Kernel is based on ThreadX. CPU is ARM core.
* ME 6-8, same kernel, but moved to PCH (formerly southbridge) and the CPU gined the GM part of GMCH. Northbridge removed from platforms. ME loses access to RAM in all states besides S0 (on) and has to make do with PRAM on PCH.
* ME9+: ME now runs on Minix and Quark CPU. Vulnerabilities become an issue.
* ME10: internal struggle for dominance between kernel and AMT teams (based in US and Israel respectively) leads to departures. (including mine)
* ME11 (12?): US team is disbanded.
So, it is a cloud then.
The system delegates the compute resources and harvests them when free. It's dynamic and elastic based on demand (and total install size).
But does that make it a bad thing prima facie?
I'm also in the "Liberal Libertarian" camp that understands "get a job" is not a viable answer to everyone in society. The system we have now is deeply flawed, and I honestly don't know how to fix it. I do believe it is unfixable in our current political environment.
how is it not a cloud?
If it follows the same architecture, layout, and usage model, then it's a cloud. A self hosted one, sure (and I would expect nothing less than self hosted from these agencies!)
Yeah, "disagree and commit" looks great on paper, but assholes gonna asshole.
And there ain't no system that can stop them. My exit was a railroad job for taking one of said assholes to HR for ethics violations. Like I said, I walked out a martyr, because while I no longer am employed there, about 50 other people are, and are no longer being abused.
You are *absolutely* correct which is why I had:
When done correctly and with trust it can make for a great team and stupendous levels of output, plus it builds trust even deeper between leadership and team.
I have seen the flipside (in fact I was the one who said "No because of Foo which will likely cause Bar and will cause Baz and if Fizz also happens then we're going to have issues"). Said manager actually did try to toss my ass under the bus for "not being clearer about my reservations". My response was the 5 page document I initially developed that was if anything over verbose.
Interestingly that manager left the company within 6 months of that kerfluffle.
In fact I believe paraphrasing Regan's "Trust but verify" into "play by the rules but keep your ass covered" is apt for any job.
I keep a "Pearl Harbor File" at home that has full documentation on everything I think may be needed. I use a portable apps install at the office to manage the live copy. The one time that there was the potential of legal action said file had my ass so neatly covered that while I still left the company and was flagged non rehirable (over my then current boss's strenuous objections) I was handed a slightly larger than normal severance package to simply go quietly into the night. My lawyer and their lawyer agreed it was best for both, my wallet agreed as well. The best part is that the line staff all knew why and I walked out of there a martyr... having already been offered employment by one of said line staff that moved to another company.
True, but that doesn't mean that you shouldn't try... you just need to be mindful that you may be in an echo chamber and attempt to break out of it.
I have found that anyone I've worked for I have been blunt and not a yes man and it has mostly gone well for me. The two times it really didn't I was saved by being shoved out because not long after I found that said team / company had severe issues and was disbanded / closed up.
Now, there is a difference between being honest and being obstructionist and that's where a lot of people screw up. My old employer had a policy of "Disagree and commit" and it makes for an awesome workplace when management and team embrace it. Management/tech leadership gets feedback, yes's and no's and the reasoning behind them. They take this information and act based on it. If you were a "no" and the decision was to move forward anyway then you commit to seeing it through, even if you don't think it's the best idea... same the other way, if you were a "yes" and it's decided to change directions you drop it and change directions.
When done correctly and with trust it can make for a great team and stupendous levels of output, plus it builds trust even deeper between leadership and team.
I had (still have) one of these beasts:
https://en.wikipedia.org/wiki/...
Tucked away in a machine that's almost never on is one of these drives (with a spare in a box).
And any company that tried to actually unify all the related OSS project pits into a coherent single user/server application suite would want to be remunerated for the effort to do so and maintain it... at which point it's going to cost as much as Outlook/Exchange so...
I completely concur that tests on all inputs (external to the system) are mandatory.
By external I mean any input from outside the code.
Last big project I worked on there were two "rings" in ring 0 code, one that faced userland and one that only faced ring 0 code. The former validated *everything* the latter, not so much. Embedded system where memory and compute cycles were at a premium.
Why can't Linux be easy?
I mean seriously, I think this illustrates very clearly why there has never been a "Year of Linux on the desktop" no matter how much we all want it.
Linux on phones ala Android is incredibly popular because it's *easy*, even if some security ground was given up to make it so.
There needs to be an enterprise friendly and home user friendly Linux that "just works" and has common business tools and home time wasters that regular folks use and want. Only then does it have a Hell's chance, and even then it's doubtful because of inertia.
Ubuntu very nearly has this licked, largely stable system, particularly LTS, easy repo installs including closed source blobs (even if you hate them, they increase usability, and thus potential market adoption), and widely available with broad platform support, but even with that it hasn't cracked the desktop.
there is a "minSKU" available that Google and Apple use that has ME alive long enough to bring up the system, do the secure boot stuff then dies.
It is now in all chipsets and is the CSE/ME (converged security engine).
I suppose you also think a spare tire is over engineering.
Technically it is.
Over-engineering is also known as planning for failure, or safety margin.
Similar to SSDs over provisioning the memory array to make up for expected failures. You know that 1TB SSD you bought? It's actually 1.25-1.5TB of raw capacity, but because they know cells will fail, rather than having drive space decrease over time they just pre-reserve a block.
In Space-X's case the over engineering of an "extra" engine increases the expected reliability, much the same way the SSD's over provisioning does. The difference is that lighting an engine after launch after you detect it's needed would be a massive design issue (and additional risk) so they launch with the whole load running. Kind of like if the 1TB SSD shipped as 1.5TB with a 5 year guarantee to still be at least 1TB.
I am reasonably new at my current (very small) company. I am the second (and still not fully dedicated) QA person.
I came from 17 years at a multinational Corp with huge QA.
To say I encountered culture shock is an understatement.
I have started implementing things like automated regression tests, and Fuzzers. My Fuzzer based tests break the shit out of things and the devs look at me with the "why would you do that?" look. They still have to go fix the issue though.
I was thinking the same thing.
Mishaps on the test stand is what the thing is built for.
Even a massive explosion with all equipment lost is a success because it thus did not happen on a launch pad where in addition to the lost equipment you very well may/will lose:
* The Payload.
* The Launchpad Facility.
* The actual Launchpad.
* Lives.
* Delay to future launches of unknown duration because of aforementioned damage.
Sure it's a suboptimal success, but it is still not a failure.
Yes it is mechanical.
For a highly analytical person it is easily graspable, because that mechanical-ness *is* analytical.
My issue isn't even with alternate teaching guides, it's that the implementation is *shit* and that's not helped when there is no context for the problems your kid brings home as homework.
https://mommybunch.com/wp-cont...
I don't even know where to start with that problem. There is no framework to understand it with.
This is the best I've been able to find:
https://i.pinimg.com/736x/b9/6...
But it's still mapping to classical division.
To add to the shitfest of CC, many of the teachers don't like it, and as a result fail to teach it very well. That leaves the kids confused as all hell.
forgot to add, this is not common core, this is considered classic:
https://www.splashmath.com/mat...
I know you're trolling but there is actually a decent point here.
There are people who just can't get classic long division, does that make them bad?
Or is it rather that instead of chucking out the entire system they should maybe consider that there are many diverse and distinct learning styles and use the one(s) suited to the students?
Also, the IEP counselor would disagree with you as she's just as baffled by the new crap (as was the teacher teaching it in the first place, who was openly hostile to it).