I worked on the BiiN project. https://en.wikipedia.org/wiki/... A 'capability' was a specific -hardware protected- feature that was set up to be unforgeable and contain access rights. This computer architecture approach date back to the Burroughs 6500 https://en.wikipedia.org/wiki/... and even back to some aspects of MULTICS.
They're definitely not von Neumann architectures, since a capability pointing to executable code is a very different thing than a capability pointing to data. In many respects, these would be "direct execution engines" for object-oriented languages (even C++, with some restrictions on that language's definition).
A huge part of this is getting over the illusion that you have any clue about the (set of) instructions generated by your compiler. If you're working on a PDP-8 or even PDP-11, C might well be close to 'assembly language'. But with the much more complex instruction sets and compiler optimizations to support those instruction sets, most languages are far removed from any knowledge of what the underlying hardware executes.
I assert that Agile is antithetical for this kind of work. It's critical that infrastructure be built to completion (in both functionality and quality). A lot of infrastructure doesn't lend itself to "requirements on 3x5 cards" For example, how would you handle "consistent concurrent updates" in a distributed system? That's an architectural/key design issue that has substantial repercussions throughout a distributed system.
I've worked on several projects producing on reliable software infrastructure. One was all new code, most others included a lot of COTS. Each had a substantial effort to capture 'architecture' and 'requirements,' including establishing what "100%" looked like so we could track progress to completion, and so the users/customers of of the infrastructure had an idea what features and capabilities they could depend on.
DevOps might work, -if- there's a substantial investment in up front architecture, design, and build planning.
(My sense of "architecture" here includes non-functional considerations, deployment issues, and even identifying human contributions to the system, i.e. how the infrastructure will be configured and maintained.)
In the past several months, a private investigative firm has been shopping around to Washington reporters a 100-plus-page dossier raising the specter of corruption on the part of senior Defense Department and private company officials in the competition for the JEDI cloud contract. But at least some of the dossier's conclusions do not stand up to close scrutiny.
Disagree. It's more convoluted than C, but adapts C's very error-prone syntax. It's more complex than Basic, FORTRAN or COBOL. It doesn't have the simplicity of Pascal nor the consistency of Java or Ada.
It's definitely a 'science experiment that escaped from the lab.'
Has your meditation practice influenced how you lead?
Having a beginnerâ(TM)s mind informs my management style. Iâ(TM)m trying to listen deeply, and the beginnerâ(TM)s mind is informing me to step back, so that I can create what wants to be, not what was. I know that the future does not equal the past. I know that I have to be here in the moment.
This makes it really difficult for an organization to determine if they're truly doing "Agile" or some bastard form. It also calls into question methods and even formal standards built on 'Agile'.
But when I've pressed Agile Evangelists on this, usually when we've had problems and I've asked, "So are we doing Agile", all I've gotten in return is, "If it's not working, you're not doing it right."
We had discussions in my (nuclear-capable) National Guard artillery unit (during the Cold War, when every artillery unit trained for that mission) whether the Chaplain's Visitation Schedule should be classified, because it might reveal the location of the firing batteries.
And that's a real issue with technical data like this. On the one hand, there's the risk of aggregation that yields classified results. That would in theory make the system holding -all that data (or a set of systems that can be 'joined' to yield the result) classified. On the other hand, there's the problem in deciding just how much aggregation yields a classified result, and then the consequences of -making that decision-. Working in a classified environment is hard (costly and very inconvenient), there's a definite incentive to avoid that if you can. (Also, the consequences if the data on your computer is decided post-facto to be classified, e.g. because of this aggregation or because it was previously mis-assessed, is a REAL PAIN IN THE ASS. They take your computer away, and you do good it get anything back from it by the time they're done assessing and then sanitizing it. Fortunately, never happened to me, but happened to co-workers.)
The rules for protecting Sensitive data are less stringent than for actually Classified data. (And just because some reporter uses the word 'secret', I'm not convinced from this article that the material was actually classified.)
If classified data was actually placed on a machine that was not properly secured, multiple people should go directly to jail. If this was a breach of a contractor system with 'FOUO' sensitive (but not classified) data, then there's a much higher bar for 'go to jail.' That being said, I'd fully expect there to be substantial consequences against the contractor, up to being kicked off and forbidden to bid on subsequent contracts.
Nissan Frontier - mice or squirrels damaged the wiring. The labor cost was even more than the parts cost, $3700 all told. Fortunately my insurance covered this under Comprehensive coverage (less my deductible, of course.)
See for example Hillier and Liebermann, Introduction to Operations Research, "Inventory Theory" (chapter 18 in 8th edition) This is basically managing the components of the inventory model to where the value of filling the order yields maximum profit. It might be really annoying (like when I got charged $1500 for a replacement wiring harness for my truck), but it should not be a big surprise to anyone who thinks about this.
That's exactly what I did have in mind. Not the concept of shared libraries, but the terrible Windows implementation of same. In particular, the total lack of discipline for where DLLs are stored. Maybe the security problems weren't obvious when Windows came up with its approach for DLL, but the management/configuration problems should have been blatantly obvious. This could have/should have been fixed in Win NT, which at least in theory started from an intellectual/design base that was stronger than Windows 3.
(I still don't understand how Dave Cutler went -so far backwards- from VMS to Win NT!)
It was a running joke where I worked in the '80s and '90s that the only reason I ran X Windows on my Sun workstation was because the scrolling in its "glass TTY mode" was so slow. There's a lot of truth to that. After X Windows launched, I launched EMACS and 2 shells. One was the command line for compiling, linking, etc, and the other was the game of Rogue I played when the compiler/linker was running.
(This was for software that did not have a significant user interface.)
And I still do stuff on the command line/Terminal.app on Mac OS X. Old habits die hard, particularly when they're very efficient at getting stuff done (and that includes muscle memory.)
Well, the whole "16'/"32"/'64" bit thing is evidence of bad original design.
There are a few assumptions in the Unix/POSIX standards on sizeof(int) that had to be revised, but in general that interface was independent of the underlying hardware register or address width.
And don't get me started on DLL - possibly the worst design decision in all of Windows (and that's saying a lot!), particularly given how DLLs proved to be a massive attack vector on Windows systems.
Dideu argues the average life of a cellphone in large part represents the satisfaction of the user with that device. And in particular, the long life of each Apple device represents the substantial satisfaction of the great majority of users of those devices. So if Apple makes money from the use of any iPhone in their Services and app sales, Apple doesn't see this as the problem that a handset maker such as Samsung sees it.
He quotes Deming: Dr. Edward Deming once said that the numbers that best define a company are two factors that do not appear on any financial statement. These factors are the value of a satisfied customer and the value of a dissatisfied customer. These factors must be multiplied by every other number in a financial statement in order to assess the prospects of the business. A high satisfaction leads to repeat purchases and referrals, growing the business; while a low satisfaction leads to ending relationships and a repulsion of potential new customers.
Maybe all the negative stories about Apple are just clickbait, because Android people love to see bad news about Apple, and Apple people read all the bad news to get upset about it.
Maybe there's a concerted effort to drive down Apple stock to allow (a) speculators; (b) Apple itself; to buy at the reduced price.
Slashdot Mirror
I worked on the BiiN project. https://en.wikipedia.org/wiki/... A 'capability' was a specific -hardware protected- feature that was set up to be unforgeable and contain access rights. This computer architecture approach date back to the Burroughs 6500 https://en.wikipedia.org/wiki/... and even back to some aspects of MULTICS.
They're definitely not von Neumann architectures, since a capability pointing to executable code is a very different thing than a capability pointing to data. In many respects, these would be "direct execution engines" for object-oriented languages (even C++, with some restrictions on that language's definition).
A huge part of this is getting over the illusion that you have any clue about the (set of) instructions generated by your compiler. If you're working on a PDP-8 or even PDP-11, C might well be close to 'assembly language'. But with the much more complex instruction sets and compiler optimizations to support those instruction sets, most languages are far removed from any knowledge of what the underlying hardware executes.
I assert that Agile is antithetical for this kind of work. It's critical that infrastructure be built to completion (in both functionality and quality). A lot of infrastructure doesn't lend itself to "requirements on 3x5 cards" For example, how would you handle "consistent concurrent updates" in a distributed system? That's an architectural/key design issue that has substantial repercussions throughout a distributed system.
I've worked on several projects producing on reliable software infrastructure. One was all new code, most others included a lot of COTS. Each had a substantial effort to capture 'architecture' and 'requirements,' including establishing what "100%" looked like so we could track progress to completion, and so the users/customers of of the infrastructure had an idea what features and capabilities they could depend on.
DevOps might work, -if- there's a substantial investment in up front architecture, design, and build planning.
(My sense of "architecture" here includes non-functional considerations, deployment issues, and even identifying human contributions to the system, i.e. how the infrastructure will be configured and maintained.)
How many errors are due to C syntax, e.g. "=" vs "=="?
At what point do we finally decide that C just wasn't the best choice for large scale long lived systems?
(And don't tell me about "experts don't make those mistakes". See, for instance https://www.researchgate.net/p... )
Here's a different view:
In the past several months, a private investigative firm has been shopping around to Washington reporters a 100-plus-page dossier raising the specter of corruption on the part of senior Defense Department and private company officials in the competition for the JEDI cloud contract. But at least some of the dossier's conclusions do not stand up to close scrutiny.
https://www.defenseone.com/tec...
Damn, my moderator points expired before I read this comment!
+1 funny/insightful
Disagree. It's more convoluted than C, but adapts C's very error-prone syntax. It's more complex than Basic, FORTRAN or COBOL. It doesn't have the simplicity of Pascal nor the consistency of Java or Ada.
It's definitely a 'science experiment that escaped from the lab.'
https://www.ped30.com/2018/06/...
Has your meditation practice influenced how you lead?
Having a beginnerâ(TM)s mind informs my management style. Iâ(TM)m trying to listen deeply, and the beginnerâ(TM)s mind is informing me to step back, so that I can create what wants to be, not what was. I know that the future does not equal the past. I know that I have to be here in the moment.
Please identify the (de-jure) standard for VBA. "Microsoft's current compiler" is not a -standard-.
This makes it really difficult for an organization to determine if they're truly doing "Agile" or some bastard form. It also calls into question methods and even formal standards built on 'Agile'.
But when I've pressed Agile Evangelists on this, usually when we've had problems and I've asked, "So are we doing Agile", all I've gotten in return is, "If it's not working, you're not doing it right."
We had discussions in my (nuclear-capable) National Guard artillery unit (during the Cold War, when every artillery unit trained for that mission) whether the Chaplain's Visitation Schedule should be classified, because it might reveal the location of the firing batteries.
And that's a real issue with technical data like this. On the one hand, there's the risk of aggregation that yields classified results. That would in theory make the system holding -all that data (or a set of systems that can be 'joined' to yield the result) classified. On the other hand, there's the problem in deciding just how much aggregation yields a classified result, and then the consequences of -making that decision-. Working in a classified environment is hard (costly and very inconvenient), there's a definite incentive to avoid that if you can. (Also, the consequences if the data on your computer is decided post-facto to be classified, e.g. because of this aggregation or because it was previously mis-assessed, is a REAL PAIN IN THE ASS. They take your computer away, and you do good it get anything back from it by the time they're done assessing and then sanitizing it. Fortunately, never happened to me, but happened to co-workers.)
The rules for protecting Sensitive data are less stringent than for actually Classified data. (And just because some reporter uses the word 'secret', I'm not convinced from this article that the material was actually classified.)
If classified data was actually placed on a machine that was not properly secured, multiple people should go directly to jail. If this was a breach of a contractor system with 'FOUO' sensitive (but not classified) data, then there's a much higher bar for 'go to jail.' That being said, I'd fully expect there to be substantial consequences against the contractor, up to being kicked off and forbidden to bid on subsequent contracts.
Nissan Frontier - mice or squirrels damaged the wiring. The labor cost was even more than the parts cost, $3700 all told. Fortunately my insurance covered this under Comprehensive coverage (less my deductible, of course.)
See for example Hillier and Liebermann, Introduction to Operations Research, "Inventory Theory" (chapter 18 in 8th edition) This is basically managing the components of the inventory model to where the value of filling the order yields maximum profit. It might be really annoying (like when I got charged $1500 for a replacement wiring harness for my truck), but it should not be a big surprise to anyone who thinks about this.
The FBI started out being run by megalomaniac, corrupt authoritarians, and little has apparently changed.
No one has accused Comey of cross-dressing, though.
Anyone seen 'proof' this GrayKey thing actually works?
That's exactly what I did have in mind. Not the concept of shared libraries, but the terrible Windows implementation of same. In particular, the total lack of discipline for where DLLs are stored. Maybe the security problems weren't obvious when Windows came up with its approach for DLL, but the management/configuration problems should have been blatantly obvious. This could have/should have been fixed in Win NT, which at least in theory started from an intellectual/design base that was stronger than Windows 3.
(I still don't understand how Dave Cutler went -so far backwards- from VMS to Win NT!)
It was a running joke where I worked in the '80s and '90s that the only reason I ran X Windows on my Sun workstation was because the scrolling in its "glass TTY mode" was so slow. There's a lot of truth to that. After X Windows launched, I launched EMACS and 2 shells. One was the command line for compiling, linking, etc, and the other was the game of Rogue I played when the compiler/linker was running.
(This was for software that did not have a significant user interface.)
And I still do stuff on the command line/Terminal.app on Mac OS X. Old habits die hard, particularly when they're very efficient at getting stuff done (and that includes muscle memory.)
Well, the whole "16'/"32"/'64" bit thing is evidence of bad original design.
There are a few assumptions in the Unix/POSIX standards on sizeof(int) that had to be revised, but in general that interface was independent of the underlying hardware register or address width.
And don't get me started on DLL - possibly the worst design decision in all of Windows (and that's saying a lot!), particularly given how DLLs proved to be a massive attack vector on Windows systems.
It's a testament to the backward compatibility of Windows itself, especially that this was originally included in Windows more than 20 years ago.
Gee, that would date this code to about the same time we were doing the POSIX standards that codified a (then) 20 year old Unix interface.
to cause cancer in laboratory animals"
Over yet another move away from "Windows Uber Alles"...
http://www.asymco.com/2018/02/...
Dideu argues the average life of a cellphone in large part represents the satisfaction of the user with that device. And in particular, the long life of each Apple device represents the substantial satisfaction of the great majority of users of those devices. So if Apple makes money from the use of any iPhone in their Services and app sales, Apple doesn't see this as the problem that a handset maker such as Samsung sees it.
He quotes Deming:
Dr. Edward Deming once said that the numbers that best define a company are two factors that do not appear on any financial statement. These factors are the value of a satisfied customer and the value of a dissatisfied customer. These factors must be multiplied by every other number in a financial statement in order to assess the prospects of the business. A high satisfaction leads to repeat purchases and referrals, growing the business; while a low satisfaction leads to ending relationships and a repulsion of potential new customers.
Two other possibilities
Maybe all the negative stories about Apple are just clickbait, because Android people love to see bad news about Apple, and Apple people read all the bad news to get upset about it.
Maybe there's a concerted effort to drive down Apple stock to allow (a) speculators; (b) Apple itself; to buy at the reduced price.
Excellent point! I was using 'monopoly' in the legal sense (at least that's what I intended, IANAL.)