> The part of the NSA that does domestic surveillance is relatively small and not nearly as intrusive as the tinfoil hatters want to believe
That claim seems to be nonsensical, given the existence of the Echelon program, and the immunity granted to AT&T for its infamous fiber optic monitoring room (http://en.wikipedia.org/wiki/Room_641A), Whether it is "relatively small" is also fairly meaningless, since it could mean "epsilon less than a majority of the budget".
I'm glad for your moral standing and peace of mind that you've withdrawn from such work. But let's be very clear that much of what the NSA is illegal, unconstitutional, and against various international treaties.
>> Will Spartan implement things in a new unheard of way or will it actually try to achieve maximum compatibility?
> MS has not done that in awhile.
Quite correct. They normally go for the same old, compatible only with Microsoft way. Occassionally they put a new twist on it, but the core is usually the old API violating structure. I'll point to OOXML as my prime example, since no Microsoft product actually follows the entire spe, and thus remains unlikely to ever be compatible, even with other versions of Microsoft Office.
> with the sole exception that all other things being equal clearly the more exciting one will pay bigger dividends due to increased developer interest.
I'm afraid that's the fine print. "All other things being equal". All other things are not equal. "Boring" technologies tend to have a competent, with documentation, load testing, and syntax checking tools. New technologies to "get the project done" often not only fail, but even when they work fail to scale, and introduce _another_ complex environment to manage.
> There is still not a really great solution to web front-end development
I'm afraid it's because "web front-end development" is about the web front end, and not about the actual content. This is precisely what broke the new Fedora installer, and breaks other interfaces that should be a flow chart with flat text. And in reality, most web pages should be flat text with minimal graphics ecause, behind the scenes, most of them are simple flow charts of flat text content with a few relevant options.
HTML can actually do this reasonably well. Javascript has some uses for it, to handle somewhat more sophisticated options like dates. But most of them do not require a sophisticated GUI. We saw the failure of "web front-end development" with the "Slashdot Beta", which remains one of the the clearest failed "upgrades" since Windows Vista..
Unfortunately, the cost of hiring one is often spending six months to re-engineer the nightmare created by semi-sophisticated developers, the nightmare which simply cannot support the next level of service or next round of customers on the original architecture. This sort of problem pays for the DBA members of my group, others of us work with other aspects of such projects.
> but online businesses have nearly no start up cost at all.
Oh, my. Advertising, wages, travel, laptops or computers, and public facing online services rack up very quickly. Even without travel, most online startups _fail_. That day of "once you have made a profit" is fairly rare for startups.
Without specialized tools or services, which may be all software but cost time and money to develop, most startups have nothing to distinguish them from dozens of other startups with the same "paradigm shift" bright idea.
The tiny editors do have their uses. They tend _not_ to require dozens of unrelated and bulky graphical packages to support them, the failure of any of which can disable the graphical editor. And they work well over poor bandwidth connections to remote servers, and even work well on overburdened, very lightweight virtualization servers for software routers or proxies.
So making them work really well can save work time and be very appreciated by people doing critical work with very real constraints.
The kernel modification is merely a shim. Much of the work in the NVidia drivers is in the replacement for the OpenGL libraries, which are heavily modified by NVidia and difficult to reverse engineer.
>> Knowing the physics of trebuchets offers no further insight into history.
>False, you're now missing the entire point of topical subjects, the core of what the whole thing is about!
The premise is also confused. The physics of weaponry provides _massive_ insight into history, warfare, and economics. The range of a trebuchet, and its cost to make, and necessary manpower to use, affects military planning quite critically in ways that translate well to modern project planning and modern warfare.
Like bust and boom economic cycles, it happens at least once in every political generation. The most radical of the hippies were a target of police abuse and harassment in my youth: Communists and socialists were harassed in the McCarthy era, and the Japanese-Americans were put in American concentration camps during WW II. So police used to control perceived native, political threats is not a new problem: the recent "war on terror" is merely the latest instance of the understandable, but dangerous, desire to turn police from public servants to the enforcers of martial law.
They said the TA's were mostly women, not the students. That's not that unusual: certainly when I attended college some decades back, women in computer science tended to be both poorer, and more driven to achieve, than the average male student. The result was a filtering that made the remaining women in the course notably more skilled, and less likely to be incredibly arrogant and abrasive, than their male peers.
It's also aggravated by the "install the latest software, and build components, from arbitrary 3rd party repositories". I'm afraid that I just a long discussion with some Java developers who were accustomed to building their software on their desktops, pulling in arbitrary, unknown versions of components and their dependencies, and and using the resulting components to build the next round..I'm afraid it's reminding me, forcibly, of Perl developers saying "just use cpan build!", and ruby developers saying "just install the gem".
If you don't pay attention to the components of your build environment, your qa environment, and your production environment, your testing cannot be reliable. That can be a very hard policy to teach, and to enforce.
Unfortunately, unicode is now woven into various Java string handling and database interactions, and it is far too complex to test all the possible input and storage scenaries. I've also noticed a strong tendency among current QA engineers to test only the new feature, and to avoid testing old components interacting with new features without _amazing_ pushback from their managers who want to keep testing costs very small. The result is a fairly predictable string of failure modes, and of production failures, that can be avoided by discarding such expensive, complicating software features as Unicode.
Or an invading foreign government can pull you out of your home and invent a new type of human called an "enemy combatant" and pretend that existing laws from both countries, , and international treaties and the US Code of Military Justice do not apply to them. It's difficult to tell the last estimate I saw said there are still more than 100 prisoners at Guantanamo Bay.
Let's be very clear that many governments, including that of the US, pick and choose what rules to follow for some quite inconsistent and quite dangerous reasons.
Let us be clear: SSL hs been demonstrated as vulnerable to top-down attacks, to signature authorities failing to protect or being willing to abuse their signature authorities. The classic example was DigiNotar, but there have certainly been other fake certificates published. If you combine this with the number of hosted web proxies and poorly managed websites with poorly protected wildcard SSL certificates on them, it's not safe to place too much trust in SSL certificates as a form of signature authority. It's too difficult to trace the "path of trust" for a certificate to have full confidence in it, especially with such carelessness in the market place.
So let's be aware that SSL is helpful against casual monitoring. But the certificates should not be considered sufficient for critical data: a separate verification channel, such as GPG signatures or checksum verifications presented on a different information channel, should be used for verification of the content of the most sensitive data, Even modest encryption practices such as "zip" encrypting a file and sending the key _separately_ can help protect data from casual man-in-the-middle attacks: I've found GPG to be more technologically robust with a very useful chain-of-trust model, but it's not well enough integrated for many of my non-technical clients to use well.
That's what the remaining few owners are hoping for. It would be like paying blackmail,and encourage other ambulance chasing intellectual property lawyers.
> He also pulls no punches when it comes to saying uncomfortable unpleasant things.
This is certainly true. I've met the man at a conference, and mentioned my attempts to bring client's and partner's work into the published, ideally free software and open source where necessary world. He considered my and their work with "software as a service" to be immoral, because all the software should be directly in their hands. We didn't have time to discuss it longer, nor to discuss the inability of most home users to maintain a robust or secure database.
I have to admire his effective technology and political leadership, even while I find myself fervently wishing that he would bathe more often.
> There's virtually no excuse to be running a website without SSL.
SSL key authentication for distant sites taking many small transactions is expensive, slows the transmissionf of the critical information, and actually presents an electricity and cooling cost on both ends. For content that is GPG signed separately, such as a bulk webiste mirroring thousands of software packages and update packages, it can be quite burdensome.
> Just try to listen to a 200 years old English recording
Name one, such recording, please. The oldest vocal recording I've heard was the Volta recording on an Edision audiograph: the first reliably known audio recordings are from the 1850's.
If your document is not in clear, precise language, then it can and will be re-interpreted by everyone who reads it. This can be vital for fiction or poetry, where the purpose is to engage the reader's imagination and create a full, vivid world with as little text as possible. But if there is no "right", then the interpretations are usually destined to be "wrong" because of the ambiguities. This is part of every language, including spoken English, written English, contracts, legal text, programming, and mathematics. If you do not have a well defined structure, you cannot define or handle exceptions.
One classic version of such ambiguity is dates. When you write "01/02/03", to You mean January 2nd, 2003, as Americans do? Or Febuaryy first, as the UK and some European nations do? Or do you follow the German convention, and mean the year February 2nd of 2001?
This kind of confusion is why we have "formal" English, so people can write 2001-02-03 and make it unambiguous, and so that speakers separated by age, time, or local history can communicate consistently. It's quite vital to a worldwide economy and political ecology, and it is _critical_ in engineering and computer science.
One of the first "homeopaths", cited extensively by modern practicioners, was Samuel Hanneman. And Samuel did _research_ in medicine. Rather than merely citing from leaned tracts, he investigated local practicioners and conducted experimented. Many of his his claims have turned to be misguided, such has his "law of similars". But his dedication to actual experimentation and verification of treatment was exceptional in his time. He was not, perhaps, a _great_ scientiest. But his claims about modest doses of dangerous substances being used to treat related illness was key to the development of vaccination for infectious diseases, and to desensitization for treating allergies. And his study of "miasms" was surprisingly close to the later discovered theories of infectious diseases: he lacked the microscopes and later, more sophisticated chemical tools to research it much further.
So please do give credit to the originator of the field, much as one gives credit to religious prophets whose ideas have been perverted. Perhaps much like one can give credit to Isaac Newton's early work in mathematics and optics and ignore most of his later, confused work in alchemy. If only the very followers of his work would understand the beginnings of scientific testing and methodology in his work and carry on from that, they might be much more helpful to their clients.
Slashdot Mirror
> The part of the NSA that does domestic surveillance is relatively small and not nearly as intrusive as the tinfoil hatters want to believe
That claim seems to be nonsensical, given the existence of the Echelon program, and the immunity granted to AT&T for its infamous fiber optic monitoring room (http://en.wikipedia.org/wiki/Room_641A), Whether it is "relatively small" is also fairly meaningless, since it could mean "epsilon less than a majority of the budget".
I'm glad for your moral standing and peace of mind that you've withdrawn from such work. But let's be very clear that much of what the NSA is illegal, unconstitutional, and against various international treaties.
>> Will Spartan implement things in a new unheard of way or will it actually try to achieve maximum compatibility?
> MS has not done that in awhile.
Quite correct. They normally go for the same old, compatible only with Microsoft way. Occassionally they put a new twist on it, but the core is usually the old API violating structure. I'll point to OOXML as my prime example, since no Microsoft product actually follows the entire spe, and thus remains unlikely to ever be compatible, even with other versions of Microsoft Office.
> with the sole exception that all other things being equal clearly the more exciting one will pay bigger dividends due to increased developer interest.
I'm afraid that's the fine print. "All other things being equal". All other things are not equal. "Boring" technologies tend to have a competent, with documentation, load testing, and syntax checking tools. New technologies to "get the project done" often not only fail, but even when they work fail to scale, and introduce _another_ complex environment to manage.
> There is still not a really great solution to web front-end development
I'm afraid it's because "web front-end development" is about the web front end, and not about the actual content. This is precisely what broke the new Fedora installer, and breaks other interfaces that should be a flow chart with flat text. And in reality, most web pages should be flat text with minimal graphics ecause, behind the scenes, most of them are simple flow charts of flat text content with a few relevant options.
HTML can actually do this reasonably well. Javascript has some uses for it, to handle somewhat more sophisticated options like dates. But most of them do not require a sophisticated GUI. We saw the failure of "web front-end development" with the "Slashdot Beta", which remains one of the the clearest failed "upgrades" since Windows Vista..
Unfortunately, the cost of hiring one is often spending six months to re-engineer the nightmare created by semi-sophisticated developers, the nightmare which simply cannot support the next level of service or next round of customers on the original architecture. This sort of problem pays for the DBA members of my group, others of us work with other aspects of such projects.
Cutting their budget also has a profound effect.
> but online businesses have nearly no start up cost at all.
Oh, my. Advertising, wages, travel, laptops or computers, and public facing online services rack up very quickly. Even without travel, most online startups _fail_. That day of "once you have made a profit" is fairly rare for startups.
Without specialized tools or services, which may be all software but cost time and money to develop, most startups have nothing to distinguish them from dozens of other startups with the same "paradigm shift" bright idea.
The tiny editors do have their uses. They tend _not_ to require dozens of unrelated and bulky graphical packages to support them, the failure of any of which can disable the graphical editor. And they work well over poor bandwidth connections to remote servers, and even work well on overburdened, very lightweight virtualization servers for software routers or proxies.
So making them work really well can save work time and be very appreciated by people doing critical work with very real constraints.
Does it have the butterfly macro for real programmers?
https://xkcd.com/378/
The kernel modification is merely a shim. Much of the work in the NVidia drivers is in the replacement for the OpenGL libraries, which are heavily modified by NVidia and difficult to reverse engineer.
>> Knowing the physics of trebuchets offers no further insight into history.
>False, you're now missing the entire point of topical subjects, the core of what the whole thing is about!
The premise is also confused. The physics of weaponry provides _massive_ insight into history, warfare, and economics. The range of a trebuchet, and its cost to make, and necessary manpower to use, affects military planning quite critically in ways that translate well to modern project planning and modern warfare.
Like bust and boom economic cycles, it happens at least once in every political generation. The most radical of the hippies were a target of police abuse and harassment in my youth: Communists and socialists were harassed in the McCarthy era, and the Japanese-Americans were put in American concentration camps during WW II. So police used to control perceived native, political threats is not a new problem: the recent "war on terror" is merely the latest instance of the understandable, but dangerous, desire to turn police from public servants to the enforcers of martial law.
They said the TA's were mostly women, not the students. That's not that unusual: certainly when I attended college some decades back, women in computer science tended to be both poorer, and more driven to achieve, than the average male student. The result was a filtering that made the remaining women in the course notably more skilled, and less likely to be incredibly arrogant and abrasive, than their male peers.
It's also aggravated by the "install the latest software, and build components, from arbitrary 3rd party repositories". I'm afraid that I just a long discussion with some Java developers who were accustomed to building their software on their desktops, pulling in arbitrary, unknown versions of components and their dependencies, and and using the resulting components to build the next round. .I'm afraid it's reminding me, forcibly, of Perl developers saying "just use cpan build!", and ruby developers saying "just install the gem".
If you don't pay attention to the components of your build environment, your qa environment, and your production environment, your testing cannot be reliable. That can be a very hard policy to teach, and to enforce.
Unfortunately, unicode is now woven into various Java string handling and database interactions, and it is far too complex to test all the possible input and storage scenaries. I've also noticed a strong tendency among current QA engineers to test only the new feature, and to avoid testing old components interacting with new features without _amazing_ pushback from their managers who want to keep testing costs very small. The result is a fairly predictable string of failure modes, and of production failures, that can be avoided by discarding such expensive, complicating software features as Unicode.
Or an invading foreign government can pull you out of your home and invent a new type of human called an "enemy combatant" and pretend that existing laws from both countries, , and international treaties and the US Code of Military Justice do not apply to them. It's difficult to tell the last estimate I saw said there are still more than 100 prisoners at Guantanamo Bay.
Let's be very clear that many governments, including that of the US, pick and choose what rules to follow for some quite inconsistent and quite dangerous reasons.
The cab stands at airports, and the cab stands near train stations have gotten regular business from me when I've been in a hurry.
Let us be clear: SSL hs been demonstrated as vulnerable to top-down attacks, to signature authorities failing to protect or being willing to abuse their signature authorities. The classic example was DigiNotar, but there have certainly been other fake certificates published. If you combine this with the number of hosted web proxies and poorly managed websites with poorly protected wildcard SSL certificates on them, it's not safe to place too much trust in SSL certificates as a form of signature authority. It's too difficult to trace the "path of trust" for a certificate to have full confidence in it, especially with such carelessness in the market place.
So let's be aware that SSL is helpful against casual monitoring. But the certificates should not be considered sufficient for critical data: a separate verification channel, such as GPG signatures or checksum verifications presented on a different information channel, should be used for verification of the content of the most sensitive data, Even modest encryption practices such as "zip" encrypting a file and sending the key _separately_ can help protect data from casual man-in-the-middle attacks: I've found GPG to be more technologically robust with a very useful chain-of-trust model, but it's not well enough integrated for many of my non-technical clients to use well.
> Can't IBM just buy whatever remains of SCO
That's what the remaining few owners are hoping for. It would be like paying blackmail,and encourage other ambulance chasing intellectual property lawyers.
> He also pulls no punches when it comes to saying uncomfortable unpleasant things.
This is certainly true. I've met the man at a conference, and mentioned my attempts to bring client's and partner's work into the published, ideally free software and open source where necessary world. He considered my and their work with "software as a service" to be immoral, because all the software should be directly in their hands. We didn't have time to discuss it longer, nor to discuss the inability of most home users to maintain a robust or secure database.
I have to admire his effective technology and political leadership, even while I find myself fervently wishing that he would bathe more often.
> There's virtually no excuse to be running a website without SSL.
SSL key authentication for distant sites taking many small transactions is expensive, slows the transmissionf of the critical information, and actually presents an electricity and cooling cost on both ends. For content that is GPG signed separately, such as a bulk webiste mirroring thousands of software packages and update packages, it can be quite burdensome.
> Just try to listen to a 200 years old English recording
Name one, such recording, please. The oldest vocal recording I've heard was the Volta recording on an Edision audiograph: the first reliably known audio recordings are from the 1850's.
If your document is not in clear, precise language, then it can and will be re-interpreted by everyone who reads it. This can be vital for fiction or poetry, where the purpose is to engage the reader's imagination and create a full, vivid world with as little text as possible. But if there is no "right", then the interpretations are usually destined to be "wrong" because of the ambiguities. This is part of every language, including spoken English, written English, contracts, legal text, programming, and mathematics. If you do not have a well defined structure, you cannot define or handle exceptions.
One classic version of such ambiguity is dates. When you write "01/02/03", to You mean January 2nd, 2003, as Americans do? Or Febuaryy first, as the UK and some European nations do? Or do you follow the German convention, and mean the year February 2nd of 2001?
This kind of confusion is why we have "formal" English, so people can write 2001-02-03 and make it unambiguous, and so that speakers separated by age, time, or local history can communicate consistently. It's quite vital to a worldwide economy and political ecology, and it is _critical_ in engineering and computer science.
I could care less.
One of the first "homeopaths", cited extensively by modern practicioners, was Samuel Hanneman. And Samuel did _research_ in medicine. Rather than merely citing from leaned tracts, he investigated local practicioners and conducted experimented. Many of his his claims have turned to be misguided, such has his "law of similars". But his dedication to actual experimentation and verification of treatment was exceptional in his time. He was not, perhaps, a _great_ scientiest. But his claims about modest doses of dangerous substances being used to treat related illness was key to the development of vaccination for infectious diseases, and to desensitization for treating allergies. And his study of "miasms" was surprisingly close to the later discovered theories of infectious diseases: he lacked the microscopes and later, more sophisticated chemical tools to research it much further.
So please do give credit to the originator of the field, much as one gives credit to religious prophets whose ideas have been perverted. Perhaps much like one can give credit to Isaac Newton's early work in mathematics and optics and ignore most of his later, confused work in alchemy. If only the very followers of his work would understand the beginnings of scientific testing and methodology in his work and carry on from that, they might be much more helpful to their clients.